Reason # 19: Enterprise Mobility Apps

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Basically, anyone who would migrate their Magic application to C# would lose out on the built-in capabilities of the Magic application platform for server-side and client-side mobile apps.  The Magic RIA client for iOS™, Android™, BlackBerry® and Windows Mobile® is a native operating system (OS) application for any of these devices, implementing the Magic RIA client protocol. Using the Magic RIA client for the different mobile devices, developers can deploy highly interactive enterprise RIA applications on the various mobile devices. This is another critical reason not to migrate Magic eDeveloper, uniPaaS, or Magic xpato .NET in C# or ASP.

Magic xpa is indeed Mobile-ready and you leverage same development effort for all mobile operating systems (iOS, Android, BlackBerry, Windows Mobile) and devices (smartphones, tablets). All C# can do is act as a piecemeal backend server in an all too complex mobile kluge, whereas Magic xpa provides a comprehensive enterprise mobility solution including real-time back-end integration and mobility management services. Let’s look at the details.

Developing mobile RIA applications using Magic xpa requires the same skill set as developing desktop RIA applications. However, since the devices’ capabilities, user interface and expected user experience are significantly different from a desktop computer, there are obviously important differences that need to be taken into account when designing the application screens and planning the user interaction.

Devices differ in screen size, fonts, expected interaction device features (such as a camera and GPS), security related features and more. Consider, for example:

Screen size and orientation – Mobile devices have various resolutions and screen sizes in both landscape and portrait orientations.

Keyboard devices – Some mobile devices have a full QWERTY keyboard. In addition to a keyboard, some devices have a dedicated Menu key, an Esc key and a trackpad or trackball that are equivalent to the desktop keyboard arrow keys. The trackpad also provides a dedicated Fire action when pressed. Keyboard-only devices have a fixed screen orientation and cannot be rotated.

Touch devices – Some mobile devices have a touch screen or hover screen, some in addition to a full keyboard, and some without a keyboard. Touch devices support screen rotation and provide an on-screen virtual keyboard when a full keyboard is not available.

Windowing model – Mobile devices support a simple stacked window model. Each application can open multiple windows, but each new window is stacked on top of the 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.

Form navigation using trackpad – Some mobile devices (such as BlackBerry) 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 (an Edit control), is done using the trackpad directional actions.

Form navigation using touch keyboard – Touch devices use an on-screen virtual keyboard. Some devices rely on tapping on form controls (fields) to navigate between the fields while others have Tab functionality in the virtual keyboard. The navigation inside a field (an Edit control), is done using a long press on the field content.

Context menu – The 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.

Input modes – The Edit control is always in Insert mode. There is no equivalent Overwrite mode on the mobile devices.

Running in the background – The mobile devices’ OS is a multi-tasking OS, meaning that each application can run either in the foreground or in the background. The end user can see the running applications and switch between them. An application running in the background is not suspended and continues to run, but does not have access to the screen.

Offline mode – Magic xpa's new offline mode allows clients to continue working on their app even when the connection has been lost and restores the application states when the connection is restored.

C# has absolutely no capability for dealing with any of these challenges while Magic xpa has built-in support for smartphone and tablet features that allow you to build apps for multiple devices with ease.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.