Writing mobile contact management and address book apps

Writing a mobile app that manages contact information is a common requirement. First you will need to describe the app in terms of its purpose, features and functions. Before jumping right into database design, first consider what standards, interfaces and models are already available.

An enterprise address book app is typically concerned with providing details about contacts for some purpose such as messaging, transactions, or relationship tracking. An address book is typically thought of as a hierarchy of lists that contain addresses. Each of these levels of an address book will require their own data and metadata. See, for example, the Address Book Object Protocol published July 26, 2013 by Microsoft Corporation. This protocol provides developers with specifications for all the properties of various Address Book objects and how these object properties relate to each other.

An address book may be stored on an address book server or cached locally on a mobile device as an offline address book (OAB). One of the standards that helps in the exchange of address book information is the vCard. The Open Mobile Alliance publishes the OMA Converged Address Book (CAB) 1.0 standard and is proposing a 1.1 standard as well. This is really a much more advanced social address book standard designed for interoperability.

Remarkably, most mobile phone address books are rather insecure. Developers of address book apps should incorporate encryption and decryption protocols into any app where security is needed. While a development environment like the Magic xpa Application Platform can provided encrypted communication between application servers and mobile clients, the developer must decide to create a secure application and implement security standards for data storage. It is not automatic (nor should it be as some situations are better suited to unencrypted data storage and communications).

Your app may also need to access address book APIs. The table below cites some of the more common email and social mail clients and their corresponding address book APIs.

Mail Client	Address Book Type	API
Any	LDAP	Mozilla's LDAP XPCOM component
Mozilla	Local address book	Mozilla address-book XPCOM component
Outlook	Outlook Personal Address Book (PAB)	MAPI
Outlook Express / MS Mail	Windows Address Book (WAB)	WAB API
Lotus Notes	Lotus Notes/Domino Address Book	Lotus C API
Google Mail	Google Contacts	Google Contacts API version 3.0
Yahoo! Mail	Yahoo! Address Book	Yahoo! Mail API
FaceBook Messaging System	FaceBook FriendList	Graph API
LinkedIn	LinkedIn Connections (requires the r_emailaddress member permission)	Connections API

Creating address book applications for mobile devices such as iPhone, iPAD, Android, BlackBerry and Windows Phone is easier with the Magic xpa Application Platform because of the built-in secure transport between client and server as well as the rich feature set for data discovery, communications and offline mode operations.

Deploying Magic xpa Applications on Android

I've enjoyed the recent series of videos on mobile development for Magic xpa Application Platform. As readers of this blog know, Magic Software's Magic xpa Application Platform allows you to build and deploy applications including mobile apps. Deploying those apps on Android emulators and Android smartphones is straightforward enough. Deployment on the emulator is presented in a recent video in the Developing for Mobile Series: "Running a Magic xpa Application on the Android Emulator." 

When it comes time to deploy your ANdroid apps, you can choose from four basic deployment methods:

The Run Method. One way to deploy an application is to run the APK file on your Android. This is usually done when you receive the file as an email attachment. All you have to do is click on the attachment. 

Over the Air Method. As you might guess from the name, the Over the Air method of deployment for Android allows you to use your Internet browser to browse to a URL on an Internet server where the .apk file is located and then click to download. For this to work, you need to put the APK file on an exposed folder on the web server. If the application does not run, configure the web server to support download of the APK file as follows: Open the Internet Information Services (IIS) manager, navigate to the Default Web Sites, open the Mime Types and add a new one as follows:

• Extension=.apk
• MIME type=application/vnd.android.package-archive
  
  Using the Android Market. 
  You can also upload your application to the Android market.To do this, you use the ADB command line utility – when installing on a simulator or on a device using a cable. You can install the APK by using the Android Debug Bridge (ADB) utility, which is located in the platform-tools folder in your SDK folder, usually at: C:\Program Files\Android\android-sdk\platform-tools.Finally, to install your APK, run the following command: adb install –r my.apk.

Enjoy the video!

Off the Hook: Introducing Offline Programs

With the release of Magic xpa 2.4, Magic xpa RIA applications have offline capabilities in addition to online capabilities for browser-free Internet and mobile apps. Magic xpa applications are comprised of multiple programs that perform specific tasks. Magic xpa Application Platform now supports the creation of RIA applications that may be comprised of both online programs that are connected to the server and offline programs that use local resources and storage. Magic xpa Offline Programs are Rich Internet/Client applications (RIA) that work while not connected to a server and store information locally on the client device. An offline program runs only on the client and will not access the server and cannot use server resources.

Because you can now build applications with both connected and offline capabilities for Windows, iOS and Android devices it is important to think through the necessary application patterns to deal with the lack of a connection to the server. Offline programs allow users to continue to be productive in areas with intermittent, limited or unavailable internet connectivity. While working offline, data is stored locally on a local database, and periodically, when internet connectivity resumes, you can synchronize it back to the server.

Offline programming requires you to overcome the limitations imposed by the challenges and constraints of working without a server connection. In contrast to online programs, the server connectivity is either non-existent or unreliable. Your apps need to be adjusted to handle this state carefully, while creating a usable app and maintaining data integrity. The challenge in offline programming is to keep the data consistent and synchronized while providing the user a meaningful experience while disconnected. Magic xpa allows you to create apps that store a subset of relevant server data or client-only data locally on the client. Magic xpa allows you to store user credentials on the client for apps that require user authentication. In a Magic offline program, data can be entered on the client and later updated for consistency with the server. This means Magic xpa now provides bi-directional data sync between the client and the server. Magic xpa ensures a seamless user experience when connections are slow or lost allowing uninterrupted operation and data consistency. A Magic xpa offline program also accesses application resources locally on the client such as application metadata and images. New tools and features in Magic xpa allow developers to overcome offline programming challenges and provide users with a rich-interactive experience regardless of connection issues.

Since Magic xpa applications can work without network connectivity or with intermittent network connectivity, new application patterns must be considered.

Startup. When you start a Magic xpa offline program for the first time, you will need to be connected. Magic xpa uses this first invocation to sync the resources that you the programmer have specified such as client-side data, metadata, and images.

User Authentication. When you want an app with user authentication, the user credentials will need to be stored securely on the client in order for authentication to occur while offline. When reconnecting, credentials should be checked again.

Local Resources. After initial startup, offline programs always use local data and images as resources. In this fashion, they always work even when there is no connection to the server. Data updates are always stored to the local device and only when connected is the matter of data consistency with the server handled.

Master-Master Synchronization. Magic xpa allows you to use a master-master pattern http://msdn.microsoft.com/en-us/library/ff650702.aspx for bi-directional data synchronization so you will need to think through your business rules for resolving data conflicts. At intervals you specify, the application will attempt to synchronize client-modified data back to the server and server-modified data back to the client. The assumption is that there are multiple clients that may be modifying data as well.

Metadata Synchronization. Magic xpa will automatically synchronize application metadata on startup or when the application changes.

Whether you need Windows, iOS (iPhone, iPAD) or Android apps in offline mode, Magic xpa Application Platform provides an ideal solution for developers of enterprise mobile apps that are fully integrated and completely native. 

In a future post, will look further into how-to create offline programs in Magic xpa 2.4 and above.

Reason # 20: We See Sharp So You Don’t Have to C#

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

I’ve said it before, at Magic “we see sharp so you don’t have to C#!” Others have said that by upgrading to Magic xpa, you “combine the wisdom of the past with the power of the future!” But let’s face it, these are just marketing slogans. Behind the slogan, however, is a truth born out of decades of effort by Magic and our customers in what can only be acknowledged as very smart technology. With Magic xpa you benefit from the combined wisdom of our community of users, our vision for the future and our long-term staying power and commitment to your support.

I’ve been asked: “What’s the best way to migrate a uniPaaS application to .NET?” By upgrading an older Magic application to Magic xpa, you will actually merge your knowledge, experience and everything you love in our platform with all the advantages of the .NET Framework and more. How can this be true? Because Magic xpa today is fully .NET based and yet it is not bound by the limitations of C# or ASP. Magic xpa should have been named magic.NET++. Then all would have been clearer.

Magic xpa provides full .NET Framework compliance and enables full integration with Microsoft and 3rd party .NET assemblies, controls and more. This brings a more attractive user interface with a modern look and feel. Our community vision has called us to make Magic xpa mobile-ready. That means you can now leverage the same development effort for all mobile operating systems (iOS, Android, BlackBerry, Windows Mobile) and devices (smartphones, tablets). The comprehensive aspect of our Enterprise Mobility Solution means we can also offer real-time back-end integration and mobility management services to our customers. And by upgrading, you help to make your existing applications future-proof because Magic xpa is constantly enhanced with new features and technologies to meet market demands and business requirements. Unlike code conversion companies that have no legitimate long-term strategy, Magic has a commitment to you and continues to provide all the support you need. Our large active developer community includes more than 3000 independent software vendors. We offer 24/7 global eService customer support, telephone support, maintenance, professional services, and unparalleled access to R&D.

For many of you reading this, your uniPaaS or eDeveloper application has served you well, but you’ve decided it’s time to upgrade. An upgrade allows you provide more features and functions leading to a better user experience. With the rise of smartphones, enterprise mobility, and BYOD, you really need to support mobile access for multiple devices and operating systems. An upgrade to Magic xpa will preserve your past investment. Upgrade to the latest version to Magic xpa and you will benefit from our mobile-ready application platform and continuous feature and technology enhancements that let you outperform the future.

But you need to beware of Other .NET Migration offers that leave you out of this community, close you off from this vision and abandon you with no real support.

Other vendors may offer .NET migration but beware, you will not be moving to a pure .NET engine, you will be locking yourself to their engine. It is simply impossible to do everything Magic does (as summarized in our twenty reasons) without proprietary or untested and unproven C# library extensions that go far beyond simple .NET. Ask yourself, what will happen when I need support? How will I migrate beyond this point? Code generators offer terminal migration and no vision for the future or commitment to platform improvements. Who will lookout for your future needs? And how will you handle the need to provide mobile enterprise apps and to add other new features and technologies?

With Magic you get the best of all worlds – full .NET compatibility, a comprehensive and cost-effective mobile-ready solution, and continuously enhanced features and technologies that enable you to best meet the demands of today and tomorrow. And I simply cannot understand the logic of moving backward to C#.

With all due respect to people who collect garbage for a living, I do not want to be a garbage collector. Moving from the Magic xpa application platform to a C# pile of code is like moving from a beautiful mansion to a garbage dump.

The frustration of programming in C# is that you spend so much of your time doing unpleasant things, like garbage collection,  that you are forced to spend less time on your real applications, more overtime evening and weekend hours working on non-productive code, or both. I don’t make this stuff up, folks. Microsoft’s “Conclusion” is very clear: “The .NET garbage collector provides a high-speed allocation service with good use of memory and no long-term fragmentation problems, however it is possible to do things that will give you much less than optimal performance.” In other words, stepping into a C# programming project means you are entering a highly risky world where you can easily spend excessive amounts of effort and end up with extremely poor performance.

C# is Microsoft’s archaic imitation of Java. We all know Java is an overly complex, bloated pile of code as well, but in C# Microsoft managed to release a language that is very poorly suited to today’s business challenges. Let’s be clear, C# is not a cross-platform mobile language. Depending on kluges like Mono, is a highly risky business strategy for creating mobile apps because the future of these approaches is highly uncertain. Mono recently had to get another $12 million to stay afloat and there is no indication that they have a strategy that will stabilize their rocky history.

C# is dependent on APIs in extension libraries. If you are only ever going to program for today’s requirements, this may be fine. But what happens when you need to run your applications somewhere new? Let’s be clear, C# is not a platform and it is not cross-platform. If you depend on API extension libraries, you are inviting yourself into a development dead-end.

Maintaining C# code is extremely difficult, especially when you are trying to work with someone else’s code. For example, a section of code can look exactly the same but behave differently depending on whether it is actually a class or a struct. I get nightmares just thinking about it.

An application platform provides a world of benefits and saves you from a world of hurt. At Magic, we see sharp so you don’t have to C#. 

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

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.

Reason # 18: Distributed Application Architecture

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

Magic xpa Application Platform utilizes a Distributed Application Architecture that offers a high level of choice between different computing environments. The interoperable nature of Distributed Application Architecture also means that Magic xpa applications have the ability to operate in multi-database, multi-platform, and multi-network data processing contexts. Using the simple interface common to all Magic xpa applications, every user, from any workstation, can access any type of local or remote database, execute queries, and update the data. As we shall see, Magic xpa Application Platform provides capabilities for distributed architecture, application partitioning, MDI, and secure communications out-of-the-box. When converting Magic eDeveloper, uniPaaS or Magic xpa to C#.NET, these advantages are lost.

In an environment where multiple computers are connected by a Local Area Network (LAN) or Wide Area Network (WAN), Magic xpa’s distributed application architectures automatically utilize a specific form of distributed processing.

Fortunately, when you install Magic xpa, you don't have to know how the distributed application architecture is set up, however you can adjust the settings if desired. The diagram below illustrates what is happening behind the scenes in Magic xpa's distributed application architecture.

The process begins when a client, such as a browser or Rich Client application, makes a request to the enterprise server. It does this via a requester, usually a Web server. Each client has its own requester.

The requester uses the broker to communicate with the Magic xpa enterprise servers. This is a Magic xpa Runtime engine (MgxpaRuntime.exe) functioning as an enterprise server. The broker scans its list of prioritized servers to find a server that is not busy and informs the requester which engine is available. If all the engines are busy, the event is added to the broker's request queue.

Once an engine has finished handling a request, the Runtime engine sends the request results directly to the client and notifies the broker that it is available to process the next client request. A check is made if there are pending requests in the queue which are for the same application as the one loaded in the Magic xpa engine. If there are pending requests, the broker extracts the requests with a higher priority and sends it to the engine.

The term application partitioning is used to describe the process of developing Magic xpa applications that distribute the application logic among two or more computers in a network. In the simplest case, the application can run on a single PC, as a remote service, and send task requests for execution to a server. In more advanced cases, the application logic can be distributed among several servers.

The first step in creating a partitioned application is choosing which components of the application run on the server system or systems. The criteria for making the choice are the components that would most benefit in performance and maintainability, if they were to run on the server. Note that the decision whether a program or task runs in the Requester Client or in the system need not necessarily be made when the application is designed, but the design must take this into consideration as only background-mode tasks are applicants for partitioning.

In Magic xpa, background enterprise servers and Online programs are multi-threaded. This gives you the ability to have parallel task execution in your projects.

Each thread accesses a different Runtime context, and does not interact with other threads. To work with multiple threads in Online programs, Magic xpa provides you with Multiple Document Interface (MDI) and Single Document Interface (SDI) functionality.

Communication between the Magic xpa client and the Web server (requester) is compressed while communication between non-Magic xpa clients (such as Web clients) and the Web server (requester) is not. The Magic xpa developer secures these communications using the https protocol. The https protocol (SSL\TLS) encrypts the communication between the client and the Web server and ensures that the server is a trusted one.

Communication between the requester, broker and engine is encrypted using Asymmetrical and Symmetrical encryption. No hard-coded keys are used and it is possible to define the Symmetric encryption mechanism and the key length.

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

Reason #17: Magic xpa has a Built-In Licensing Mechanism

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

One of the deficiencies of C# as it compares to Magic xpa is that it lacks any sort of licensing mechanism. Licensing is important for software publishers who want to use Magic xpa to create and protect commercial software. It also provides an added measure of security and risk prevention to corporate software users. Licensing mechanisms help to prevent unlicensed software usage and therefore reduce the risk that a company can be sued for copyright and other violations. When considering migration of Magic eDeveloper to C#.NET or ASP.NET or Java (or uniPaaS or Magic xpa), it is important to consider your need for licensing mechanisms.

 Magic xpa’s built-in license-metering mechanism uses your local area network (LAN) to communicate between Magic xpa instances running on different machines on the network. As part of our ongoing commitment to comply with the latest and highest industry standards, Magic introduced a new policy for the activation of our software licenses in 2012. The improved process, implements a highly secure, automated method of license protection, enabling you to better monitor the use of your licensed software.

You activate and receive your licenses after validating your Product Key on Magic’s License Activation Portal. The metering mechanism helps organizations avoid any unintentional violation of the license. The license-metering module ensures that no more than the allowed number of connections uses Magic xpa concurrently.

Magic xpa includes a license management scheme. The license management system comprises three main components: a License File, which stores all the license information for a specific site; the Magic xpa Engine, which uses data from the License File to allow or prevent user access to an installed Magic xpa product; a License Server, which provides license information to the Magic xpa engine, and also counts the active users of the installed product.

Magic xpa offers three license modes: no license, demo license and permanent license. The Magic xpa License File, when initially created, contains a default demo license. This demo license has no time limit but is limited in its functionality and cannot be used for the development and deployment of mission-critical applications. Permanent licenses have no time limit. When you load Magic xpa with no license, essentially without specifying a license name, the Single User Edition will run.

The single-user limitation is relevant for both the development of the application, as well as its deployment. Magic xpa Single User Edition provides almost the complete range of features found in the commercial edition of Magic xpa, excluding multi-user related features and capabilities.

Magic xpa also includes convenient mechanisms for counting licenses and running floating licenses. To count licenses, you can run MGSTATIONS.exe from the Magic xpa directory to verify the license count of a specified license on a network.

Magic xpa's default behavior is that you have to define the number of licenses that each server uses during the execution of a project. This number is checked across all the servers in a multi-project environment to ensure that it is within the license limitation. For example, if you have a license with 20 threads, and you have two projects running in a multi-project environment, you have to distribute the threads in advance. Project A might receive 15 threads, while Project B receives 5.

In a multi-project environment, each server runs a different project. This means that the capacity of each server (project) is a key issue, and the ability to share licenses (threads/users) is very important.

Magic xpa's floating license mechanism lets you make optimum use of these licenses in a multi-project environment, by sharing licenses between servers. Therefore, when a particular project is idle, other projects can utilize its licenses.

Because the Magic xpa broker controls the servers and their capacity, it needs to know the total number of licenses that are available for its servers. The broker adds up the total maximum threads and users belonging to each server. The broker uses this figure as the total number of available threads/users. If the broker sees that a particular server is not using its allocated number of threads/users, the floating license mechanism means that they can be used by other servers.

Using C# to manually license software is a fool’s errand. Using C# to bind in a third-party licensing scheme is also very expensive and time consuming. The advantage of the Magic xpa Application Platform is that licensing is built-in to the platform as a protection to both corporate end users and software developers.

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

Reason #16: Straightforward Security Management

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

Magic greatly simplifies security issues for developers, giving them the power to create highly secure applications without a lot of hassle. This is another reason why Magic eDeveloper or uniPaaS to .NET migration via C#.NET is a mistake compared to upgrading to .NET with Magic xpa.

User rights management is simplified in Magic because the developer and administrator/supervisor use Magic xpa’s built-in Authorization System, Active Directory or LDAP. The Authorization System enables developers and certain users to control access to Magic xpa projects in Studio modes. This control is achieved through setting access keys to various Magic xpa project elements, and by assigning specific rights to users and user groups.

As a repository based system, Magic xpa is vastly superior to the tedious coding required for rights management in C#. The Magic xpa Rights repository lists the name and keys of all the rights defined for a project. The developer can define a bank of rights and assign them to the project's various repositories and elements. Any project element that has an access right assigned to it will be blocked to users who have not been assigned this right. Project-layer security is always defined during development.

In addition, Magic xpa includes a flexible authorization system to control what each user can and cannot do in Magic xpa. The authorization system lets the application developer or system supervisor limit access to various activities in Magic xpa to those users specifically authorized to have such access.

The authorization system exercises its control through sets of rights and the use of built-in Magic xpa functions. Rights can be thought of as keys to locks. Rights assignments connect users, who are classified by role, with the application’s components, which are classified by accessibility. This means that certain classes of users are allowed to access certain parts of an application.

The person in the role of Supervisor can assign rights that give each user access only to the activities for which that user is authorized. Any activity that is not specifically restricted by the Supervisor or the developer remains accessible to all users and does not require any rights assignment. To access the authorization system repositories, the developer must log on to the system as a user which has the SUPERVISOR GROUP assigned to the user. This group is reserved by Magic xpa, and is automatically included in any Magic xpa system. In addition, a Supervisor user (which has this group assigned to it) is also automatically included in any Magic xpa system.

Typically, when one is implementing a security system in Magic xpa, rights are granted according to the user’s job function, which corresponds to a Magic xpa Group. That is, a user who is a bookkeeper will have a different set of menus and screens than a person who is in Sales. Other rights, however, may only be granted to certain individuals, such as the ability to approve paychecks or adjust time cards.

Managing rights in C# can be like looking for a needle in a haystack. Instead of having to search through potentially millions of lines of code to find everywhere that a role is checked, Magic xpa provides a single, consolidated location known as the Rights Repository. What a nightmare it would be to have to parse an entire code base to learn and document what roles are assigned to what permissions.

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

Reason #15: Magic xpa Surpasses C# in Interoperability for .NET

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

The Magic xpa Application Platform is a particularly strong platform in terms of interoperability of applications. While C# .NET is designed to be proprietary, Magic xpa Application Platform, while .NET based, is designed to deliver greater interoperability. This is one of many reasons why converting a Magic eDeveloper, uniPaaS or Magic xpa application to .NET in C# using a code generator makes no sense. 

Developers looking for fully .NET applications should instead upgrade to Magic xpa.

That’s why Magic xpa provides direct support for technologies like Java, SNMP, MSMQ, JMS, WebSphere MQ, LDAP, Active Directory, Java Script, VB Script, Client Certificates, Dynamic Data Exchange (DDE), IMAP, POP3, etc. All of these internal Magic xpa functions provide direct support for technologies that are otherwise quite difficult or impossible to support with C#.NET. 

The ability of a single programming environment to interface with so many different, unique and tedious environments at a high-level provides tremendous advantages, reduces risk and helps to future-proof your applications. For example, Magic xpa provides direct  Java support including support for Java classes and objects called in a Magic application and Magic applications exposed as Java classes and objects for use by Java programs. 

The idea that C# can handle a converted Magic application is ludicrous. Sometimes developers have no choice but to deal with older technologies like DDE. So even though you might be able to convert your code, without the Magic engine, there is no automatic way for raw C# to handle DDEs.

Let’s look at another simple example like SNMP. Magic xpa supports Simple Network Management Protocol (SNMP) functionality. This lets Magic xpa programs and the Magic xpa engine (the broker and the requester) send SNMP compliant messages to a monitor. It also gives the system administrator control over various Magic xpa modules via an SNMP monitor.

SNMP governs network management and monitors network devices and their functions. Magic xpa is SNMP enabled, so the Network Management Station (NMS), also referred to as an SNMP monitor, can query and manage the Magic xpa broker (including its registered enterprise servers) and the Magic xpa broker can report traps (alarms, failures, or other exceptional events).

Messaging is another great example of Magic’s superior interoperability compared to C#. In distributed applications, two different applications often need to communicate with one another to transfer information. One of the ways to accomplish this is message queuing, which ensures guaranteed delivery.

Message queuing lets applications send messages without waiting for a reply and to continue with other processes. Other applications can receive the messages at their leisure and continue processing according to the data received.

Message queuing is a method by which program instances can exchange data using an interface to a system-managed message queue, which is managed by the operating system. Application programs create message queues, and send and receive messages using an application program interface (API).

There are two main ways to send messages:

Send / Receive – This is used when there are one or more senders who want to send messages to one receiver. Each message is addressed to a specific queue, and the receiver extracts the message from the queue.

Publish / Subscribe – This is used when there are multiple senders (publishers) and many receivers (subscribers). The publisher sends messages to a central location, the topic, which sends the messages to anyone who has subscribed to this specific topic.

Both of these methods provide the user with guaranteed message delivery and are supported out-of-the-box with Magic xpa. Not so with C#.

Every access to the message queue is done using a set of functions, such as open, close, and send. Magic xpa provides a message queuing component with interfaces to three standard messaging queue systems: MSMQ (Microsoft), JMS, and WebSphere MQ (IBM). C# does a passable job only with MSMQ.

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

Reason #14: Web Services

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

Today's entry in the reasons not to convert Magic eDeveloper, uniPaaS, or Magic xpa to C#.NET code is Web Services. If you ask Microsoft how-to incorporate Web Services into an application, they simply refer you to ASP.NET. Why? Because C# is considered an unsuitable match for developing programs that publish or subscribe Web Services.

But let’s suppose you decide to be stubborn and persist in migrating your Magic Web Services to C# which uses a line-by-line coding approach.

In a simple example, just to pass a SOAP header, your C# code would look something like this:

<%@ Page Language="C#" %>

<asp:Label id="ReturnValue" runat="server" />

<script runat=server language=c#>

 void Page_Load(Object o, EventArgs e)

 {

  MyHeader mySoapHeader = new MyHeader();

  // Populate the values of the SOAP header.

  mySoapHeader.Username = Username;

  mySoapHeader.Password = SecurelyStoredPassword;

  // Create a new instance of the proxy class.

  MyWebService proxy = new MyWebService();

 

  // Add the MyHeader SOAP header to the SOAP request.

  proxy.MyHeaderValue = mySoapHeader;

  // Call the method on the proxy class that communicates with

  // your Web service method.

  string results = proxy.MyWebMethod();

  // Display the results of the method in a label.

  ReturnValue.Text = results;

 }

</script>

Here’s how you do it in Magic xpa: interact with the dialog box Header field.

Also, when consuming Web services (either by using the Invoke Web S or Invoke Web S Lite operation), the Magic xpa engine does a lot of work for us.

Magic xpa lets you call a Web service directly or uses the Systinet Web Services framework (named "Systinet Server for Java") for providing and consuming Web Services.

Magic xpa provides rich Web Services support including:

·         SOAP 1.1 and SOAP 1.2

·         WSDL 1.1

·         WS-I Attachments Profile 1.0

·         MTOM/XOP support

·         WS-I Basic Profile 1.1 Compliance

·         Transport level security – SSL\TLS

·         WS-Security 1.0 – authentication, encryption and digital signing of SOAP messages

Ask yourself this question: Is my company in business to write programming code? If writing code is not your business and not at the heart of the charter of your company, then why spend so much time managing code when you can manage applications that support your business instead?

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