Consumers need to be able to find your store locations from any location. Retail location awareness is part of the basic DNA of any retail chain. Writing a basic Magic xpa Store Locator app for a mobile
device should be a fairly straightforward effort for an experienced Magic xpa
developer. A basic Store Finder or Store Locator application has an input table and an output table. This is no different for the mobile app.
The input table is the information provided by the user.
Typical input fields
Field name*
|
Field attribute
|
Field description
|
LookupRecordID
|
Numeric
|
The unique identifier for the
record
|
Address1
|
Alpha
|
The street address of the record
|
City
|
Alpha
|
The city of the record
|
State
|
Alpha
|
The state of the record
|
Postal
|
Alpha
|
The ZIP or Postal code of the
record
|
Country
|
Alpha
|
The Country of the record
|
* The developer can
use any name for these fields, the field names here are just examples.
Typical output fields
Field name*
|
Field type
|
Field description
|
Longitude
|
Alpha
|
The longitude of the output
geocode
|
Latitude
|
Alpha
|
The latitude of the output geocode
|
Quality
|
Alpha
|
The quality of the output geocode
|
Coordinates
|
Alpha
|
The coordinates of the reference
polygon
|
StatusOK
|
Alpha
|
Debugging info from the geocoding
process
|
With the Magic xpa Application Platform, the developer can
create mobile client apps that leverage the devices' GPS. With Apple iOS
devices, for example, the ClientOSEnvGet function can be used to
query the current device location using the internal or connected GPS device.
Function syntax in the Magic Application Platform is selected in an intuitive
table driven development wizard interface. So for example,
ClientOSEnvGet (‘device_location’) will return the current device location, using
available location options such as GPS or Network. The result is an ALPHA string
in the following format: “OK|Latitude|Longitude”, where OK is
a fixed part for testing if a result was returned, and Latitude and Longitude are
the coordinates of the current location. If a location could not be obtained,
for any reason, an error message will be returned. The results of this function
may be parsed to provide the StatusOK, Latitutde and Longitutde fields in the
example above.
With your backend system, information for store locations may
not be in an obvious place. Yes, it will have an associated address book table.
In JD Edwards, for example, address book info is stored in a F0101 table. But
not all F0101 records contain your store locations. These will also include
employee addresses, customer addresses and other business units such as plants
and distribution warehouses. The business unit info will be stored in the F0006 table in JD Edwards, Business Unit Master table which
Contains Business Unit Descriptions and Category Code Information. The
Magic xpi Integration Platform will give you an easy way to query these and
other tables needed to piece together the necessary information. Other ERP
systems can be accessed in a similar fashion.
Magic xpa stores string information with an attribute of ‘Alpha.’
Alpha allows the storing of alphanumeric characters.
In the Alpha attribute, Numeric characters are stored as a string. The Alpha
attribute is the default attribute.
Magic xpa stores numbers with an attribute of
‘Numeric.’ The numeric attribute allows the storing of an integer or a decimal
number. Magic xpa supports up to 18 digits, with the condition that the number
of whole digits and decimal digits are each rounded up to the nearest even
number.
In addition, you can determine where you may
need to employ logical, date, Unicode, time, BLOB, OLE, ActiveX, Vector or .NET
data attributes.
With these basics in mind, creating a Store Finder app or
Store Locator app is very straightforward with Magic xpa. Enterprise Mobility for retailers becomes a rapid reality with Magic xpa Application Platform.
No comments:
Post a Comment