Showing posts with label meap. Show all posts
Showing posts with label meap. Show all posts

Thursday, January 3, 2013

Creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform


Writing a basic Magic xpa Customer Service or Help Desk app for a mobile device could make a great weekend mobile app development project for a Magic xpa developer.
Magic xpa does a good job of making it easy to handle the huge variety of data types, by insulating you from the details of the implementation.  Magic xpa reduces the number of data attributes (often referred to as data types in many programming languages) that you will need to work with -- alpha, numeric, date, time, BLOB, logical, etc. are the most common. The Magic xpa programmer also does not need to specify how those variables are actually stored in memory or in a database as the application platform itself manages these repetitive and inconsequential details for the developer.

To create a mobile app for customer service or an employee help desk, a few tables that might typically be required are the user table, the ticket table, the solution table and the solution response table. Many other variations are possible, of course, depending on the complexity of service/help app required. We’ll take the time to detail the fields used in the user table and the ticket table. But keep in mind that the tables will all have relationships.

For the sake of efficiency both in data storage and application performance, you should avoid creating duplicate data. So if, for example, the solution proposed relates to a specific ticket, there is no need to store all the ticket details in the solution table. You can simply point to the unique identifier of the ticket table. This is the principle of data inheritance. The data inheritance or data model relationships in our example are shown here:


Now let’s look at the User Table and Ticket Table.

Typical Customer Service App fields – User Table
Field name*
Field attribute
Field description
PrimaryID
Numeric
The unique identifier for the record.
UserFirstName
Alpha
The first name for the record
UserLastName
Alpha
The Last Name for the record
UserEmail
Alpha
The Email for the record
UserMobilePhone
Alpha
The mobile phone number of the user or device.
UserEmployeeID
Numeric
An integer value containing the employee ID for this record
DepartmentID
Numeric
An integer value containing the department ID for this record


Typical Customer Service App fields – Ticket Table
Field name*
Field attribute
Field description
TicketID
Numeric
The unique identifier for the record.
Status
Alpha
The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Severity
Alpha
The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Subject
Alpha
Brief subject of the problem described in the record.
Description
BLOB
A detailed description of the service issue.
CreateDate
Date
Date record was created.
CreateTime
Time
Time record was created.


* The developer can use any name for these fields, the field names here are just examples. In addition to the above, you’ll want to think about tables that contain the problem, description, and BLOBs containing the communications between the service rep and the user (the solution and response table), as well as tables containing service rep information, etc.

The challenge in creating a mobile help desk or customer service app for end users is that screen space is very limited on most mobile smartphone devices. The user information should be entered once, and then it need not appear to the user again unless they request to change it, for example, the user may need to change their phone number or email address. If you wanted to pre-populate the UserMobilePhone field, in theory this can be queried using a user defined function such as  ClientOSEnvGet ('device_udf| UIDevice currentDevice’) on iOS, for example, or the user can simply enter their mobile phone number.

Once the user identity is established, the home screen for the mobile app should be the list of tickets with open tickets bolded or listed in red at top in order from most recent to oldest. Only two columns are needed, Ticket and Subject. The user can select a ticket and then the detailed ticket tab opens with the ability to scroll down through solutions and responses. On an iPhone, these could be displayed as colored speech/conversation bubbles whereas on the android you may choose to display in the more conventional android style.

I think its fair to say that creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform makes for a great intermediate level programming project. What will set the good CS apps apart from the bad ones? Creative features such as customer self service knowledge bases could create real differentiation. When the type of service involves parts and repairs, location information of the device becomes even more relevant. How might you utilize location knowledge in your app to locate parts? to locate service centers?  

What sets the great mobile enterprise application platforms (MEAP) apart from the others? Integration, unified development approach, enterprise-class scalability, security and reliability. 

Thursday, May 17, 2012

Magic Application Platform: “Take Me to Your Developer!”



Just when you thought you would never like a cross-platform mobile development platform, Magic Software has introduced a MEAP platform that makes sense. Previous MEAPs were either frustratingly uniform in their approach to user interface design or overly limiting in the way a native app could be designed for iOS.  The Magic xpa Application Platform iOS client has finally landed and the news is very, very good. It may seem like it was a long way coming, like an alien from a distant planet but “We’re Here!” and we are saying loud and clear: “Take Me To Your Developer!”

The Magic iOS client is a native device OS RIA application designed to take advantage of iOS mobile device capabilities, while being connected to a scalable, robust enterprise server. For those familiar with the Magic Application Platform, the Magic iOS client implements a subset of the capabilities of the Magic RIA client for .NET Desktop, as they are applicable on an iPhone or iPad device.

And you get loads of native device capabilities.

Let’s Play “Where’s Waldo?” er, “Where’s Waldo’s Phone?”

With the Magic Application Platform  the developer can create applications for the Magic iOS Client that leverage the devices' GPS. The ClientOSEnvGetfunction 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 a 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.

Is a Picture Worth a Thousand Words?

The applications you create can also use the camera in the iOS client using the Magic Application Platform’s  ClientFileOpenDlg function. Be sure to specify the path as camera, so that the camera will be opened.  This will enable the user to take a picture and select it. The full path name of the picture will be returned from the function. It is then possible to upload this picture to the server using the ClientFileToServer function, or by loading it into a BLOB variable.

Developing Apps that Access Miscellaneous iOS capabilities on iPhones and iPads

In situations where it is possible to use device capabilities such as calling a phone number, sending an SMS, sending an email and opening a browser, the developer can create app capabilities for that. On the Magic Application Platform the developer can leverage iOS device capabilities by using the Invoke OS command with the URL of the required command.

All of the following examples would be valid parameters for the Invoke OS command:
          tel:1-408-555-5555
          sms:1-408-555-1212
          http://magicsoftware.com


More than Window Dressing for iOS

Of course the Magic xpa Application Platform delivers more than just window dressing for the iOS Client. Your developers can now build Magic mobile apps that run in a native iOS client and perform important business transactions. These apps are also easily targeted to Android, BlackBerry, etc. Regardless of which mobile client is connected, they can all access the same backend Magic Enterprise Server. So your boss can use your app on his iPhone, your colleagues can strut your apps on their BlackBerry devices and you can run it on your guilty-pleasure Android.

OK, now that you have taken the Magic xpa Application Platform to your developer, take it to your leader and get the mobile apps you need today!

Wednesday, May 16, 2012

What is a mobile enterprise application platform (MEAP)?



What is a mobile enterprise application platform (MEAP)?

MEAP, n., mobile enterprise application platform, an integrated development and deployment environment allowing for a single basis of development for multiple native client experiences across a variety of smartphones. 

Gartner says that: "A Mobile Enterprise Application Platform (MEAP) is a development and deployment framework that provides tools for client, server and middleware for mobile. Targeting any mobile application on any device, ranging from a smartphone to a tablet;  multichannel and offline capabilities.  Best for companies that wish to deploy multiple applications on a single infrastructure, scaled to the size of their current mobile offering and available in an online and offline mode."

Ideally, a MEAP provides a unitary approach to the development and deployment of software for smartphones and tablets, i.e. mobile apps.  Without a MEAP, the development effort grows exponentially and many enterprises have already wasted millions of dollars only to discover how difficult it is to develop for multiple, changing target mobile platforms.

As Jones et. al. put it: “Take for example a small apps company developing for iOS, Android and Windows Phone 7. They would have to employ three teams of developers, as often, skillsets don’t mix. They would have to maintain three different codebases, and synchronize feature additions and bug fixes across the three. This is a daunting challenge, and one reason why many apps are launched across stores with months of delay. Furthermore, quality and design consistency will vary when multiple developer teams are involved, and especially when the development for a new platform is outsourced to a third party. Support costs are also difficult to contain when developing for multiple platforms, as developer documentation needs to be built for three platforms, as does the internal customer support documentation.” (Jones, et. Al., VisionMobile: The Clash of the Ecosystems Report, February 2012, VisionMobile).

A MEAP provides an enterprise IT team with  way to leverage a singles skillset – development capabilities in the MEAP language or paradigm – and still have the ability, perhaps for the first time, to produce mobile apps across a wide variety of devices: iPhone, Android, BlackBerry, Windows Phone, etc.

While it may not be true that a consensus has formed around the idea that a MEAP is the only way to viably develop and deploy enterprise mobile apps for mobile devices, a significant community coalition is forming around this approach. As CIO.com states: “"Consumerization of IT" may be an overused phrase, but it is by no means a fad. Workers nationwide are coming to expect that personal devices will connect to corporate networks.”  So the pressure is clearly being placed on IT departments to create mobile apps that run on a variety of devices. It is important that IT decision makers divorce themselves from their own religious zeal about their own favorite mobile platform and realize that we live in a pluralistic society, so to speak, when it comes to mobile devices. In today’s modern and technologically divergent world it is impolite to try to impose one’s own mobile device bias on another.

MEAPs are not immune to the debate over HTML5 vs native. Even a mobile platform such as Magic Software’s application platform which supports both HTML5 merge and native deployment via specific native RIA clients on each platform is finding itself stressed to take sides in the HTML5 debate.

As Jones et. al. state: “The perennial question for many developers is whether to use a web-browser approach to deploying mobile apps, or whether to create native applications. Web apps provide a large addressable market, at the cost of web-only distribution and a comparatively shallow experience. Native apps allow for much deeper device integration and experiences, but at the cost of a platform-specific addressable market.” (Jones, et. Al., VisionMobile The Clash of the Ecosystems Report, February 2012, VisionMobile).

But Krebs and Klein are less ambiguous with their opinion: “However, for enterprises looking to develop sophisticated mobile B2B and B2E applications across a variety of mobile platforms to a large number of users leveraging a MEAP currently represents the most viable option.” (Krebs & Klein, Native & HTML5 Mobile Apps: Not an either or, but a where and when…, February 2012, VDC Research.)

This bias against HTML5 is understandable. In recent compatibility tests, HTML5 was found to be less than a third compatible with the Windows Phone 7.5 Mango browser.  HTML5 was closest to being compatible with the Firefox Mobile 10 browser and even then it was barely two-thirds compatible.  

Compliance fragmentation is not without cost. “The result of this “compliance fragmentation” is that web app developers have to spend copious time and resources in cross-optimising their web apps for the major smartphone platforms. Perhaps most notable is the case of Assanka, makers of the Financial Times popular HTML5 app, who took 24 man months to create the news reader HTML5 application for the iPad, and another 12 man months to port that same application to Android.”  (Jones, et. Al., VisionMobile The Clash of the Ecosystems Report, February 2012, VisionMobile).

And all of these technical fragmentation issues are occurring even as GUI standards are shifting; Business Processes are being “unbundled”; and Business Apps are being designed to compete for attention in the “attention economy.”  In short, expectations are at an all-time high while standardization seems to be at its lowest point ever.

To overcome the lack of standards, enterprises need a shortcut.  “MEAPs are perhaps best positioned for enterprises looking to develop sophisticated enterprise-grade mobile applications that leverage multiple data sources scaled across various devices and OS platforms and are offered to a multitude of employees.”  (Krebs & Klein, Native & HTML5 Mobile Apps: Not an either or, but a where and when…, February 2012, VDC Research.)
Jones et. al. concede:  “The cross-platform tools market is in a state of abundant developer volatility. Comparing the CPTs developers are currently using vs. planning to use or abandoning, we see continual flux, as developers try a tool, and then churn to a different one. This is a market with no clear winners or losers. It’s a market where there is little developer loyalty, and perceptions are still being formed. This is a great time for wellfunded vendors to establish a beachhead of developer marketing and inch themselves apart in terms of mindshare.”  (Jones, et. Al., VisionMobile The Clash of the Ecosystems Report, February 2012, VisionMobile).

Magic Software (NASDAQ:MGIC) is fortunate in that it is one of the largest MEAP vendors in the market and the only entrant with a pure-play attitude, well established and scalable broker technology, and global reach.

Deploying apps from Magic Software’s application platform is highly flexible. All of the platform-specific options for app deployment are supported by Magic Software including vendor app stores. Magic apps can be launched from the home screen in iOS or the app drawer on Android devices. Magic provides an amazingly mature and well-established WYSIWYG drag-and-drop, form-based environment with table-driven settings used to define the business logic.

As the mobile enterprise application platform or MEAP approach gains favor amongst a growing number of large and midsize enterprise IT departments, Magic Software will benefit from the lion’s share of the new business being generated for MEAP platforms. MEAP is a mobile app development concept that must be taken seriously in today’s era of cost-conscious IT spending amidst rising consumer and business expectations.


Additional important concepts:

Monday, April 23, 2012

Defining the Mobile Enterprise




Mobile Enterprise, n., a business whose primary nature or strategic advantage derives from the agility attained by deploying a significant proportion of its workforce in a mobile fashion and facilitating their interaction with customers, suppliers and one another without primary dependence on a fixed location.

In attempting to define the mobile enterprise, Rahul C. Basole, PhD of the Tennenbaum Institute at the Georgia Institute of Technology proposes that:

The mobile enterprise is built on a foundation of processes and technologies allowing full access and instrumented insight to all organizational resources, resulting in improved adaptability, access, and interaction among employees, customers, partners, and suppliers, independent of location.

His work remains useful in defining and understanding the mobile enterprise to this day. As Basole notes, the mobile enterprise can be comprised of two groups of workers, those who primarily work on-site and those whose work is normally performed off-site or independent of location. In the first group of on-site workers are the desk workers, on-site rovers, and site wanderers. In the second off-site group are the tele workers, off-site rovers, road warriors and global cruisers.

The initial response to the overall need for enterprise mobility has been to develop ad hoc native smartphone applications to serve the needs of many of these workers.  Gartner believes that the need for enterprise IT departments to create mobile apps quickly and easily will cause the Rapid Mobile Application Development (RMAD) sector to grow rapidly. 

Recently, I was at the largest independent gathering of Oracle Software users in Las Vegas and while on-site conducted a live webinar with Microsoft. The challenge of enterprise mobility is an increasingly hot topic in business today. Users of enterprise systems have traditionally been deskbound workers and mobile, or off-site workers as Basole defined them, have often had access to little more than email, making them fully dependent on their office bound colleagues for execution of simple tasks.

With the introduction of the enterprise mobile mashup and secure mobile computing, users of mobile apps on a wide variety of platforms can directly access relevant data and execute context sensitive and mission critical business processes from the convenience of their smartphone or tablet devices. This evolution in capabilities provides revolutionary possibilities for business success. 

Gartner believes that by 2018 a majority of business enterprises will leverage RMAD to develop mobile apps. As the largest and most established vendor in this segment, Magic Software is positioned to take early advantage of this market by offering enhancements and extensions to business processes as well as through "mobile first" development.

Monday, February 6, 2012

Mobile-to-Mobile Integration in the Cloud



The Super Bowl is over so it’s time to kickoff a super idea: “mobile-to-mobile integration in the cloud.” We’re all thinking about it but we’re just not saying it: the current end game is to have millions of mobile apps on billions of mobile smartphones all integrated via the cloud. The IT department will consist of one person, the CIO, who outsources all IT functions to a team in India/ China/Brazil /Ukraine/Tanzania (you choose), who implements the CIOs ideas based on a series of virtual use case interviews on a bunch of transparent virtual machines up in the cloud. Every pertinent interaction and piece of data created and consumed on one user’s smartphone is instantly and securely available as needed by all other players in the business process. Far fetched? Do you disagree that this is where we are heading?

When you think about it, Magic Software’s applicationplatform, mobile offering and integration platform combined with its planned cloud offering have all the components needed to make this happen, except of course for the cool as a cucumber CIO that it would take to have the guts to implement a strategy like this. The coming metadata world is so highly virtualized that it’s possible to use the world’s best infrastructure without owning anything other than smartphones.

That being the case, the future of software development is in mobile app development and cloud applications. As we move into the present capabilities more fully we will see a future where Mobile Enterprise Application Platforms (MEAP), Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) are so ubiquitous that mobile-to-mobile integration in the cloud is not only expected, it will be demanded by business users.

Holding all of this back is simple adhesion to existing systems. But here again, if one can find a nearly transparent way to integrate existing systems with mobile-to-mobile integration in the cloud then organizational resistance is futile. Business leaders will drive the process of mobile-to-mobile cloud integration forward as the cost of dynamically creating integrated applications and apps becomes less than the cost to maintain the current state of data center possessing IT departments which are typically weighed down by excessive Java overheads and heavy, overlapping middleware solutions. 

The pressure from smaller fiercely competitive organizations using agile concepts and metadata driven solutions will force Big IT to break ties with old ideas and embrace the mobile-to-mobile cloud integration future. In the meantime, billions of the rest of us will happily type on big keyboards safe inside the protection of our client server applications behind the firewall as colleagues foist loads of data over the firewall via Web applications. Either way, the technology sounds like Magic to me.



Wednesday, September 28, 2011

Overcoming the top three mobile app design & development constraints



Mobile app developers have to be the ninjas of programming because they have to get in, get the job done, and get out without consuming a lot of resources.

There are two ways to overcome the common mobile app design and development constraints: the first is to design around them using brute force, not very ninja like, and the second is to design more efficiently based on a mobile enterprise application platform like uniPaaS. Let’s consider some of the common constraints and how you can do both: design around them and design more efficiently by using a true mobile app development paradigm for enterprise and (dare I say it?) even consumer apps. My comments here will be primarily based on developing for BlackBerry mobile devices, but he same uniPaaS application platform and the general efficient principles of design will also apply to Android, Apple iOS and Windows smartphone development.

Limited Memory. Creating an application that requires less memory will improve the user experience by improving response times and reducing the likelihood of errors. Unfortunately, memory management in Java and Objective-C is extremely time consuming for developers. So regardless of which mobile enterprise application platform (MEAP) you are using you will want to design efficiently. If a field isn’t vital, eliminate it from the app or relegate it to optional views and call for the data only when needed. By using the uniPaaS application platform, you can leverage server side resources to deliver just the data you need when you need it and the best thing is, you don’t have to write any of the code for the underlying architecture or the client. You simply leverage metadata to control your app and the Magic Engine does the rest. To be clear, you avoid the need to program directly in Java or Objective-C altogether. It isn't like Magic, it is Magic!

Limited Battery Life.Battery life has less to do with the efficiency of data usage (although that is clearly one factor) and has more to do with efficient use of the radio. Apps that constantly poll the server for new data, for example, will heighten battery use and frustrate users when the device is drained. In traditional enterprise apps, polling the server across a LAN is a cheap resource and so developers tend not to give it much thought. But in a mobile app it is an even more important issue. Fortunately, the uniPaaS BlackBerry client is very efficient in its use of the radio and you don’t have to manage memory manually at all. This greatly reduces development time and ensures application efficiency and performance.

Limited Screen Size.
The BlackBerry OS supports a simple stacked window model and as with all smartphones, the screen is quite limited in size compared to desktop applications. Developers need to focus on the users’ task at hand, literally.  Do this by displaying only the immediately relevant info and any directly related tasks. Keep it simple and yet functional.

 With a BlackBerry, each application can open multiple windows, but each new window is stacked on top of previous windows and is inherently modal. As there is no mouse pointer, windows cannot be manipulated (moved or resized) by the end user. When an application is run, its main window (and subsequent stacked windows) occupies the entire device screen. How does one navigate then? The context menu is often the best way. The BlackBerry context menu is an important and central user interaction tool. Since the screen size is relatively small, it is common to perform most tasks using the context menu, instead of “wasting” screen space on buttons and on-screen menus.

Unlike most other smartphones, most BlackBerry devices are optimized for keyboard navigation and input. Typically, the trackpad is used to navigate between fields on the form, while the Fire action is used to select values and perform actions. Unlike a desktop keyboard, there is no TAB key so there is no standard key to move to the Next Field or the Previous Field. All navigation between fields and inside a field (i.e an edit control), is done using the trackpad directional actions.

Other Considerations. These top three constraints aren’t the only ones you need to consider, but they are the most important. You should also consider the impact of the longer latency caused by slower mobile bandwidths (compared to LANs) and the fact that smartphones have less raw processor power than desktop clients. All of these issues are mitigated by use of Magic Software’s mobile application platform. Happy developing! For additional information, please contact the Magic Software Enterprises branch near you.

Thursday, September 8, 2011

The Benefits of Metadata Driven Development


Eyal Pfeifel, Magic Software’s Chief Technology Officer, recently sat down to discuss metadata driven development. In the video, he provides a useful definition of metadata driven development: “Metadata driven development means developers build business applications using metadata and not using code. Metadata is a high level definition of business objects like forms, dialogs, validations and other things that are part of a business process that build a business application.”

Eyal Pfeifel contrasts metadata driven development with traditional coding or manual programming. “Unlike code which is tied to a specific platform or operating system, metadata is a high level definition and theoretically can run on any platform or operating system. Given that you have the appropriate runtime engine, you can build an application built using metadata on any kind of a device, server or client,” says Pfeifel.  
As Chief Technology Officer for Magic Software, Pfeifel certainly knows what he is talking about when it comes to traditional programming languages. Magic Software uses these more difficult third-generation languages (3GL’s) to create the metadata driven platform that is integral to Magic Software’s higher level and more intuitive application platforms. For this reason, he is keen to recognize the benefits of the metadata paradigm over traditional programming. “One of the main benefits of working with a metadata driven development paradigm is that since metadata objects are high level business objects it is possible to build a complete business application in a much shorter time than it would take when using code.  And the same business logic that you can construct one time very easily is relevant for multiple platform and operating systems like desktops, servers and even mobile devices.”
As Magic Software introduces its impressively expanding capabilities as a mobile enterprise application platform provider, Pfeifel has found himself commenting a lot recently on one of his favorite subjects: mobile application development.  “Using a metadata driven platform it is very easy to extend an enterprise application that originally started on a desktop or on a server into mobile devices because once you have the runtime engine running on a mobile device, it can theoretically run any type of application that you built on a desktop,” Says Pfeifel.  “And you can extend your business processes into a mobile device without needing to rewrite the application from scratch and with minimal adjustments just to cater for the smaller screen size or different form factor of the mobile device.”
Magic Software has a strong reputation for providing expertise that can future-proof your application development investments. As one can see by sitting down with Eyal Pfeifel, Magic Software's future-proof expertise is based on extensive customer feedback, strong R&D investment and the mindset to continually think ahead. To learn more about the Magic application platform, visit magicsoftware.com.


Friday, May 13, 2011

Mobile Enterprise Application Platform: Any App...

Enterprise mobility is in part a decision about “how to” develop and deploy mobile applications but it also involves serious questions about “what” applications to deploy. The fact that a good mobile enterprise application platform can make core enterprise software systems accessible remotely by a handheld device does not necessarily mean that all data and functionality should be exposed. Serious decisions need to be made about which data is accessible and which business functions are to be mobile-enabled. In this regard, it is important that you have all the tools in place to allow you to selectively integrate enterprise applications rather than simply providing wholesale access to your back end systems and processes.

With the announcement of Magic Software’s Mobile Offering yesterday, a new discussion of the importance of complex mobile business process and workflow was begun. See for example, the article in Dr. Dobbs Journal subtitled: “complex workflow support for mobile deployment of enterprise apps.”

Magic Software offers the mobile enterprise application platform you need to develop and deploy mobile apps and it provides the integration platform that enables connectivity and data interchange with your existing enterprise applications. Rather than engaging in extensive retooling of an existing application, you can use Magic Software’s iBOLT integration platform to automate the orchestration of data transformations, business transactions and application messaging with backend systems.

This automated approach to integration is the first step in reducing the effort required to mobilize any application. We then return our consideration to the mobile enterprise application platform itself. As a metadata engine, Magic Software’s uniPaaS application platform is a ready‐made business application engine containing pre‐written technical and administrative functions and services. It frees the developer to bypass the intensive technical code‐writing stage of application development and move quickly and efficiently to deployment.

The easiest way to grasp this concept is to see uniPaaS in action. The uniPaaS development environment is really a visual representation of application ‘assets’ and business rules stored in XML based ‘metadata’. This metadata business structure can be easily transferred from one deployment scenario to another (for example, Windows Mobile to BlackBerry) with minimal effort. And as discussed in our previous entry, it isn’t a matter of developing one core application and force fitting it onto various devices. Applications designed for iPhone and Android should have the unique look and feel of those devices. Instead, Magic Software’s Mobile offering allows you to customize your core business application for each device without having to refactor your core business logic or data structures.

For more information, please click here to download Magic Software’s Mobile Offering FAQ.