Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

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

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

Before you get into the thicket of C#.NET, ASP.NET or Java programming, you might just want to consider how much more difficult it is to deal with transactions in these manual languages than it is with the Magic xpa Application Platform. These 3^rd Party Vendors offering Magic Software Migration services forget that you are going to need to write your own code in C#.NET, ASP.NET or Java to make up for the transaction capabilities of the Magic xpa Application Platform.

Business applications frequently require transactional programming techniques. How easily one can program a transaction depends on the language and platform. The Magic xpa Application Platform enhances the .NET platform making it possible for Magic programmers to create transactions with significantly less effort than C#, ASP.NET or Java developers.

Transactions are an integral part of developing data-bound applications. A key to developing applications in a database environment is the ability to optimally use transactions to ensure data integrity.

The word “transaction” is used very often when discussing SQL applications. A transaction is an integral part of a process, contributing to the composition of the whole application, and it can be defined as the execution of a set of logically related data modifications, which must be committed (completed and written to disk) or aborted as a single unit.

This means that either the entire process succeeded or the entire process failed. There is no middle ground. Several operations such as UPDATE, DELETE and INSERT may create a single unit. Only if all the operations are successful, will this logical unit be successful.

A transaction process may be an entire business logic process or a smaller unit that is part of a business logic process.

Transactions can be used to secure Read operations, as opposed to Read/Write operations. A Read transaction ensures that the data read within the transaction is not modified by other users.

The transaction processing technique automatically logs all of the updates of a transaction to a temporary transaction file. The updates in this file are cleared only when the transaction is complete, that is, the updates to all the regular database tables have been completed successfully. If a problem is detected in any of the tables affected by the transaction, the entire transaction is canceled and the database is rolled back, that is, restored to its original state before the transaction occurred. The rollback uses the information stored in the Transaction Log file to restore the project.

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

There are many challenging issues when implementing transactions using C# or ASP.NET. The first problem is isolation. The volatile resource must adhere to the isolation property of ACID, lock the underlying resource it manages, and prevent access by multiple transactions. However, C#.NET and ASP.NET only offer thread-based locks, which prevents access only by concurrent threads, not concurrent transactions. The second problem is state management. The resource manager needs to enable the transaction to modify the state of the resource and yet must be able to roll back any such changes if the transaction is aborted.

Magic xpa offers extensive transaction-handling capabilities that avoid heavy manual programming efforts in C# and Java. For additional information on how an upgrade is superior to  3^rd Party Magic Software Migration conversion please convert here.

Reason #3: Checking and Debugging

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

Reason #3: Checking and Debugging

What vendors offering Magic  Software Migration based on conversion misconstrue is the benefits of the debugger and checker in Magic xpa. When you upgrade to the latest version of Magic xpa you get an enhanced checker and debugger that leverage the increasingly platform-based nature of Magic development in the last ten years.

Reason #3: Checking and Debugging

Application maintainability is greatly enhanced through superior checking, debugging and error logging. Remember, in C# there is no official cross-platform runtime so any notion of being able to debug a cross-platform application within a single IDE is out-the-windows, forgive the pun. But even worse, and even if you just plan to deploy in windows only environments, you basically find yourself having to write a ton of code in order to debug your code.

Contrast that nightmare with Magic xpa where when you are in Debug mode, you can run a program in Runtime mode and the Debugger will park on the Studio read-only screen at the exact location of where you are in the program when a breakpoint is reached.  

In the Magic xpa Debugger you can:

·         View breakpoints and variable values within the task flow view. Breakpoints enable you to halt execution of the program at a specific location in the Studio screen.

·         View the Magic xpa flow within the Studio using the Activity Monitor.

·         Set conditions for the breakpoints.

·         Create a Watch list that includes selected variables to be watched during runtime.

·         Update variable values during deployment. When you update a value in the Debugger, you are prompted to confirm recomputation.

·         View the flow from within the Studio.

·         View the call stack.

·         Switch between different contexts for debugging.

·         Dynamically handle logs using the Logging function.

·         Execute the Debugger remotely.

Magic xpa also has a good syntax checker, which will tell you if an object has any problems. The errors, if any, will be displayed in the Checker Result pane. You can control how these messages are displayed.

Checking and debugging requires extensive manual programming in C# and Java and misses out on the quality assurance features built into platform based computing approaches. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason #2: Cost Savings

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

Reason #2: Cost Savings

One of the logical fallacies put forward by vendors offering Magic  to .NET conversion is related to the idea of cost savings. When you upgrade to the latest version of Magic xpa you get full access to the .NET platform without all of the manual programming overhead that a non-platform based language like C# automatically entails.

Cost reduction is easily demonstrable in the upgrade from Magic v5-8, eDeveloper and uniPaaS to Magic xpa. Magic Software offers an ROEI Assesment Document to help you calculate the savings made possible by an upgrade versus the significantly higher (order of magnitude) costs associated with converting an application and maintaining it into the future.

Reason #2: Cost Savings

In narrative form, these cost savings can be summarized as follows. First, Magic xpa yields development productivity increases when creating new components, features and enhancements to your Magic application. Second, given the improvements in the development capabilities in Magic xpa, the costs of maintaining or modifying the application vs. C# or Java are reduced by as much as an order of magnitude.  Third, as it is faster to implement Web services, development time and cost will also be reduced with Magic xpa vs. C# and similarly tedious languages. Magic xpa differs from older versions of Magic in the way it implements and consumes Web services. Fourth, by eliminating the need for a database to store code/instructions (Btrieve) , you can save costs by moving to Metadata / XML. It also improves performance for the application & developer.

If you convert older Magic applications to C# or Java code instead of upgrading, your business logic requires manual programming to implement all of these improvements. No one knows this better that the companies who have made the mistake of converting. Their hiring patterns since converting their applications show a marked increase in the need for non-Magic developers. Not only does this leave Magic developers looking for a job, it ends up costing these companies a fortune to hire two to three times more developers to maintain an application in a non-platform environment. Upgrading is a more efficient way to leverage your Magic application and modernize your application. As stated previously, all development becomes manual in C# and Java and loses the significant inherent advantages of platform based computing. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason #1: Superior Developer Productivity versus C#, ASP, or Java

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

Reason #1: Superior Developer Productivity versus C#, ASP, or Java

I'm starting a series of articles for those deciding between Magic eDeveloper or uniPaaS to .NET conversion by upgrading and Magic eDeveloper or uniPaaS to machine code generators to C#, ASP or Java. The topic for today is developer productivity.

Many longtime followers of the advantages of Magic development will recall that Magic developers repeatedly won the international development competitions of the 1990s. Not only did Magic teams win multiple years in a row, they also were winning every place in the contests. They had to stop having the contests because the advocates of defeated languages stopped showing up. Why bother? Magic developers had proven themselves superior in all respects.

Everyone knows that the environments for the development of business applications have grown increasingly complex in the two decades since those amazing victories. And while it is tempting for followers of C#, ASP and Java to try to put forth claims that they have caught up to Magic’s development capabilities. The reality is that the gap has widened. As environmental complexity has increased, the Magic paradigm of platform based metadata development has become even more essential to development efficiency.

To understand this, one needs to consider the COCOMO II Model of software estimation perfected at the USC Center for Software Engineering. (Go Trojans!) The COCOMO II model can be simplified as follws:

Effort = (Team) x (Tools) × (Complexity)^(Process)

The concept is fairly simple. As you increase the number of developers (team), effort increases. As you increase the number of programming languages needed (tools), effort increases. And as you increase the functional requirements of the application to be delivered (Complexity), effort increases. The relationship between these three components of effort is factorial. Why do you think third party companies are offering so many different conversion paths for Magic (C#.NET, ASP.NET, Java, etc.)? Because to replace all of the development capabilities of Magic require not one new tool but an entirely new set of multiple tools. Migrating to .NET by converting to .NET with a  code-generator instead of migrating to .NET with an upgrade to .NET with Magic xpa will create a bubble in the center of the COCMO II formula above the number of tools needed for enterprise application development goes from Magic xpa to:

·         C#.NET            or Java J2EE for Server Side Apps

·         ASP.NET or Ruby on Rails or PHP for Web apps

·         Java J2ME for BlackBerry client apps

·         Java J2SE for Android client apps

·         Objective C for iPhone and iPAD client apps

·         Microsoft Silverlight or Adobe Flex for RIA clients

 Now consider that you can accomplish all of the above with one toolset: Magic xpa Application Platform. The Magic xpa Application Platform can create client-server apps; Web apps; BlackBerry, iOS, and Android mobile apps; and RIA apps. Magic xpa = all of the above. As a result, the value of “Tools” in the COCMO II model is 1. In essence, Magic xpa adds zero effort.

Lest you conclude that you should just stay with eDeveloper or some older version of Magic, however, let me remind you that Magic xpa is a huge improvement over eDeveloper. In essence, upgrading to Magic xpa brings the value of Tools to less than 1, further reducing effort.

Magic xpa introduces development productivity enhancements that dramatically decrease new function development time, and increase maintainability for existing functions. These are only a few examples of the many enhancements developers enjoy when using Magic xpa:

o   New IDE look and feel – By grouping dataview and logic statements under different tabs and allowing collapsible code snippets, developers find it easier to navigate the code

o   Functions – By enabling developers to create functions, developers can create cleaner and leaner code, increasing reutilization of code snippets.

o   Debugger – The new enhanced debugger allows stepping through code, adding break points, variable watches, and real time debugging, dramatically enhancing maintainability and bug fix delivery times.

o   XML integration – By exposing XML files as data sources, Magic xpa enables developers to consume and provide web services, completely removing the need to read, write and analyze XML files.

o   The Project File – Magic xpa utilizes XML source files. This creates a faster development environment, eliminates the need for a RDMS system to manage code, and enables usage of standard version control systems.

o   Web Services – Magic xpa differs from eDeveloper in the way it implements and consumes web services, to facilitate an enhanced web service offering Magic xpa leverages Web Services standards for SOAP and RESTful Web Services.

o   SubForms – The subform is a new UI control in Magic xpa which revolutionized the way developers create, develop, design and call subtasks.

o   Argument Matching – Magic xpa has full argument matching on task calls and automatic parameter creation on event handlers which eliminate code syntax errors

o   Line Level Comments – Allow eliminating inline documentation, therefore enabling cleaner and more readable code without forgoing documentation and allowing hint and developer help creation,

o   Studio and Runtime Separation – Allows developers to test application crashes without breaking the development studio therefore creating stronger and more robust applications.

o   Multi Tasking – By allowing parallel execution of programs, Magic xpa allows developers to create a productive user interface for application customers.

o   .NET Controls – Magic xpa is fully .NET based therefore creating a better looking and native looking user interface for the application customers.

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

End Programming Nightmares: Event-Driven Programming with Magic xpa Application Platform

Have you ever had that nightmare where you arrive late for an event and don't know how-to handle yourself? Everyone else seems to know what's going on, but you haven't a clue. Here's how-to avoid programming nightmares with Java and C#: Don't program in Java and C#. Magic xpa Application Platform avoids these nightmare programming scenarios and gives you a platform for an event-driven dream come true instead. 

Event-driven programming in the Magic xpa Application Platform allows for the flow of the program execution to be triggered by events and handled in a desired manner. Event-based software development in Magic xpa is based on the very powerful Magic xpa engine.

The Magic xpa engine distinguishes the Magic xpa Application Platform from other approaches to application development and deployment. With pre-built capability to perform complex data manipulations that are transparent to the developer and end-user, the Magic xpa engine is key to the productivity and performance provide by Magic Software’s approach to application development and deployment.

The engine includes a set of operations for the developer’s use in creating applications. It also serves up a structure of execution steps called logic units, which work with the operations to perform tasks for the end-user. The developer doesn’t have to tell the Magic xpa Application Platform how-to do its job. The engine already knows how to perform such actions as opening files, reading records, sorting, displaying data on the screen, and more.

Contrast this with traditional 3GL and 4GL languages where the developer has to provide detailed instructions through program code to tell a program how-to implement each and every step, regardless of how tedious and repetitive they are. Programmers developing in Java, C# and other languages get very frustrated by the fact that they have to repeat programming done hundreds if not thousands of times before by others. Many throw up their hands on the whole process of programming and say “Been there, done that” while others almost seem to enjoy being slaves to their code. By contrast, Magic xpa saves the developer considerable amounts of time by supplying these built-in operations and execution steps.

Naturally, the Magic xpa engine includes extensive support for event driven programming. Events, triggers and handlers are built in concepts. Magic xpa lets you define the Magic xpa logic as a response to implicit and explicit events that may occur during the execution of a task.

In Magic xpa, an event is an abstract indication to the runtime engine that something has occurred within the running application. The runtime engine can either choose to ignore the event or respond to it. For example, a mouse click on a control issues an event in the runtime engine that a click has occurred. The runtime engine can then respond to this event accordingly.

Every event is triggered when the application runs. Some events can be triggered as a response to an external activation, such as when a key is pressed or when the mouse is clicked. Other events can be triggered when a certain stage in the application is reached, such as an elapsed time period. Some events can be defined as triggers of other events.

A handler is a logic unit that runs when an event has occurred. A handler is defined to handle a specific event.

For the Magic xpa developer, an event is simply a logical definition of an occurrence. An event can be handled by an event handler to perform a flow of operations that the developer chooses. An event can also be assigned as a trigger of another user-defined event. When the triggering event is raised, it triggers the user-defined event. But Magic xpa isn’t just aware of events, it also allows the developer to handle events very specifically. In Magic xpa, a handler is a set of operations designated to be performed when a specified event is raised.

There are a number of different event types managed by Magic xpa.

System events are triggered by defined keystroke combinations. Magic xpa developers can define keystroke combinations for system events in a dialog box.

A Magic xpa internal event is usually handled by Magic xpa itself. But you can define a new or additional handler for these internal events.

Additional user events can be defined in the Event repository by the developer.

Timer Events within Magic xpa are based on durations, so that for every time interval of a specified duration, the event is invoked.

Expression Events are vents that are triggered when an expression evaluates to True. If the expression evaluates to false, then the event is not triggered.

Error Events are invoked when database-related errors occur such as a duplicate index or record that has been changed by another user.

ActiveX events are still used in some programs that use COM objects and Active X. An ActiveX event is raised for COM objects. If the event has built-in variables, they are created in the handler. It should be noted that ActiveX events are not supported with rich client tasks.

.NET events are preferred in rich client mode, where Magic xpa includes full support for .NET variables and events. When an event has built-in variables, they are created as parameters in the handler with the relevant .NET type. You can also define an event handler without defining a variable. In such a case, you can write the object from which you want to select the event.

Magic xpa events can be project-related events, triggered during the execution of any of the project's programs or task-related events confined to a specific task in which they are defined or to the task and its subtasks.

An event can have more than one trigger and more than one handler. Each trigger can raise the event in a different scenario. One or more handlers can handle the event for each scenario. This allows for complex event driven programming while avoiding the complexity of line-by-line coding. An event handler logic unit is the actual response to an occurring event.

When an event is triggered, the runtime tree is scanned from the bottom-most task up to the Main Program for a handler that corresponds to the triggered event. (The runtime tree is the collection of all the tasks that are currently running under the same context. The task order in the runtime tree is the order in which they were opened.) The engine sequentially executes the operations defined for the handler once it has been found. After executing the last operation in the handler, the engine continues up the runtime tree looking for another matching handler. After reaching the Main Program and executing any handlers found, when the triggered event is an internal event, the engine looks for internal engine handlers for the triggered event. The Main Program is the parent program of all other programs in the project, and it is always at the top of the runtime tree at runtime. This means that a handler defined in the Main Program is a global handler for the entire project.

Handlers of the same event, which are defined in the same task, are executed according to their location in the Task Editor from the bottom upwards.

End Programming Nightmares. The Magic xpa application platform is available commercially from Magic Software Enterprises.

Developing for the Web: Merge Technology

Who does the heavy lifting in a Magic xpa application mashup? Is it HTML5, CSS3, JavaScript or the Magic xpa Application Platform? 

To better understand mashups in Magic xpa, we need to remember that Magic has supported merge applications in general and HTML merge specifically for nearly two decades. The basic idea is not new, but all the players have been improved.

As readers of this blog know, Magic xpa Application Platform’s hybrid deployment capability provides support for a wide range of deployment architectures. On the client, these include on-premise (client/server), desktop, Web (HTML5), browser-independent Web 2.0 rich Internet applications (RIA), cloud-enabled software-as-a-service (SaaS), and multiple mobile platforms, including Android, iOS, BlackBerry and Windows, and on the server, Microsoft Windows, Sun Solaris, IBM AIX, Linux and IBM i. All of the various deployment modes are defined in the same application metadata and development project—meaning that application changes can be done once and are automatically propagated in any deployment mode.

Magic xpa’s Studio and ready-made business application engine utilize and interface with all major frameworks, such as Java and .NET, all major databases, and all communication standards and protocols. The question is, with so many options, how do we use Magic xpa to produce HTML5 mashups, or more accurately, HTML merge applications?

HTML Merge-based Applications

Magic xpa lets you design and develop an application for the Internet or Intranet by using: HTML and Java-based interfaces. Any HTML browser on any platform can access a Magic xpa application based on HTML Merge functionality. The Merge technology lets the developer create dynamic Web pages on the server side as a response to HTTP requests.

Concept

Using a set of tokens that are embedded in a regular HTML/XML file, the Magic xpa Application Platform Enterprise Server can merge any application data into the HTML or HTML5 file to produce a dynamic Web page. Magic xpa also uses form models to simplify the inheritance of GUI and other properties across multiple merged Web pages. You can also use any HTML5 editor to create your HTML5 template pages. Magic xpa

Every request for a dynamic Web page activates a corresponding batch program. This program can receive data from the request, such as submit form variables and cookies, process the application data according to the request information, and process the application logic to produce the merged Web page result.

From the Form editor, you can edit the HTML directly, either by zooming on the form from a Merge program, or by clicking on the HTML Editor in a browser-client program. By default, Notepad is the editor that appears.

However, you can choose which editor you want to use. Using an editor designed specifically for HTML, such as Front Page or Dreamweaver, can be useful.

Characteristics

Page Mode Execution

The interaction between the browser and the server is usually manifested in the retrieval of new pages as a result of a request submitted by the previous page.

Compliancy with All Browsers

The developer can choose the HTML/XML version for the application’s Web pages and any other use of client-side scripts and modules. The developer can decide on the level of Web browser compliance by choosing the HTML/XML version and additional modules.

Application Logic

The logic for merging application data into standard HTML files is server-side logic. Any client-side logic required for the application can be integrated with the Magic xpa-generated dynamic Web pages in the form of client-side scripts, such as JavaScript or VB script, and client-side modules, such as ActiveX controls and Java applets.

Controlling the Interaction

The fact that the application logic executed by Magic xpa is server-side only and that the developer determines the client-side logic, including the available hyperlinks, provides full control of the level of interaction between the client and the server.

Context Management

Any request handled by the Enterprise Server is handled independently with no correlation to previous requests submitted by the same application context for a given end user. This means that the application flow context management should be constructed and maintained by the developer.

Considerations

The Merge technology is suited for lightweight interaction between the browser and the server. This technology is designed for applications that mainly receive whole pages on each request.

Network Throughput

The number of interactions between the server and the client is relatively low and the amount of information passed from the browser to the server in every interaction, for example an HTML form’s submitted information, is also low.

However, the result page for every request may be large as the page always returns not just the new processed data but also the entire HTML portions that define the interface and design.

Given the fact that the volume of information passed from the client to the server, i.e. the uploaded data, is usually low, excluding file transfers, there is no need for a large throughput from the client to the server, i.e. the upload rate does not need to be great.

You should try to make your pages as light as possible or make sure that the end user machines have sufficient download capabilities.

Client Machine Requirements

Unless the developer chooses to enhance the pages with various objects, such as ActiveX controls and Java applets, no special requirements are set for the client machine.

Unknown Users

The ability to create applications supported by all browsers lets you freely distribute a Merge-based application with no need to know the end-user machine specifications or count licenses.

Client-side Scripting Skills

If the Web application requires client-side logic, the developers need to acquire knowledge and skills in client-side scripting. Alternatively, the HTML can appear inside the Magic xpa client, such as a Magic mobile client.

So this leads us to the question we started with? Who does the heavy lifting? I think each technology plays its role in a mashup or merge application. Magic xpa does the heavy lifting in terms of the data layer and the logical layer. Familiar web technologies such as the browser, HTML5, CSS3 and JavaScript can be used for client side interactions. 

Quite often, a pure Magic xpa rich client application can replace the need for HTML merge. Increasingly, we are seeing RIA apps on the Internet that allow a single developer to build the client-side and server-side apps without scripting approaches. Whenever this is possible, it is preferred and Magic xpa does all the heavy lifting, leaving HTML5, CSS3 and JavaScript in the dust. 

Mobile Marketing and mCommerce: What Works and What’s Worse

We’re all familiar with the mCommerce statistics:

• In-excess of one third of all consumers have made at least one mCommerce purchase with their mobile devices.  (Source: Local and the e-tailing group, 2012).
• Two-thirds of mobile users have located a business using their mobile device before making an in-store purchase (Source: Google, 2011).
• Two-thirds of shoppers use a mobile device to research or buy while shopping more than a fourth use two different devices. (Source: Local and the e-tailing group, 2012).
• More than 60% of consumers hunt for products online for at least half of their shopping trips (Source: GMA/Booz & Company Shopper Survey).
• More than half of all cell phone owners use their phones in-store for shopping comparisons and other information to help them make a sound purchasing decision (Source: Pew American & Internet Life Project, 2012).

Businesses are spending billions of dollars on mCommerce solutions, branded apps and mobile marketing, not all of it well spent. It’s time to ask what works and what’s worse? We all know that mobile marketing has a role in branding, product launches, lead generation, developing customer relationships, social and affinity marketing, channel strategy and much more.

But what works? Is it mobile websites, gamification, branded apps, messaging, social media, video, mobile search, location-based content or are there newer emerging trends that marketers and eCommerce managers need to be aware of?

In this “social-mobile” era many businesses are worried that they don’t have what it takes to compete. Maurice Saatchi, of M&C Saatchi, yes that Saatchi, has some reassuring advice: “As brands increasingly come to embrace mobile, they need not be baffled or even intimidated by what lies ahead. Legitimate concerns such as tracking, return on investment and technical complexities can be assuaged by working with a partner who can take all of the worry away.”
But the challenge isn’t simply technical. In a world of post-modern communications where the medium is the message, choosing the right mobile marketing approach is essential.

GEICO's Brostache App Quirkily Cool

The first debate that you will hear is the site vs. app debate. Those who advocate sites usually point to the efficiency of communicating across multi-channels. Those who advocate apps focus on the experience itself, immersion and loyalty.

Mobile marketing tactics such from search to gaming are always better when they are context aware. That means being location sensitive and purpose-driven. Why is my consumer or prospect interacting with their mobile device in this place at this time? Why this device (most of us have multiple choices)? Figure that out and you have a much better chance of choosing the right mobile marketing vehicle.

I really don’t see a single vehicle that is inherently better or worse. What works is innovation, creativity, and insight into the customer. What’s worse is imitation, inappropriateness and ignorance of customer expectations.

With that in mind some vehicles are better for certain mobile marketing situations. Going beyond the obvious b2b and b2c discussions, each product type and consumer type will be better or more poorly suited to particular mobile marketing tactics.

Mobile Sites. By now, every website should have a corresponding mobile site. If you don’t Google will punish you in search results and worse, you will lose out on the potential value from mobile search and mobile surfing. A well-designed mobile site that offers a high level of interaction, utility and useable on-the-go information can form the foundation of a good mobile marketing strategy. Your mobile website should be the home base of your mobile apps as well providing downloads, support and useful information.In addition, your mCommerce site will be home to a large volume of transactions from your customers.

Mobile Apps/Branded Apps. Mobile apps have proven to be the most effective overall vehicle used in mobile marketing and mCommerce. Mobile apps dazzle customers and prospects with rich interactive media content and the highest levels of interaction and intelligence. Your mCommerce apps can be integrated to back-end systems so that you are always making inventory-aware offerings for maximum profitability and consumer appeal. From browsing, to recommendation engines, to payment processing, an mCommerce app is a key part of your arsenal. And don’t forget, your app isn’t just a product sales vehicle it is a marketing machine. The marketing geniuses at GEICO didn’t invent the Brostache branded app for nothing.

Mobile Ads. Placement of mobile ads on popular sites is a good way to generate traffic for your mobile sites and apps. Remember that targeting is as essential to this form of advertising as any other. But if your objective is mobile commerce, you’re already half-way there because your ad reader is already using their mobile device. With the MMA and others collaborating to help standardize ad sizes and formats, the advertisers ability to approach mobile advertising like any other advertsing buy is improving.

Mobile Coupons. First-party mobile coupons seal the deal when a consumer is on-site and ready to purchase but are not as effective when the consumer has to find a way to keep track of your coupon on their mobile device. That’s why third party mobile coupon providers are more effective, because you can go back to their app to provide multiple coupons. A consumer may find a way to keep track of a first party coupon that will save them large amounts of money, but nobody wants to access multiple sites or apps in the grocery store to save a penny or two on canned soup.

Mobile Contests. Mobile contests encourage consumers to divulge their mobile number. Building a base of engaged mobile users can be powerful. All you have to do is pick a prize and ask your audience to text in with a mobile keyword to enter.  These contests are great for brands that can effectively leverage a text relationship with a consumer. So these will tend to be consumer-oriented or established relationships.

Mobile Gaming. Sometimes called advergaming, gamification of advertising and marketing messages allows a brand to reach consumers and potential customers in a fun, dynamic and engaging way. Depending on your objectives, games can be an effective way to build affinity, awareness and even loyalty. The best games have product placement without distracting from the fun or the challenge.

SMS Messaging. SMS marketing messages can take on many forms based on the context. SMS broadcasts, SMS polls, SMS contests, SMS Autoresponders, etc. Mobile messaging and location-based mobile messaging can be tricky business because you have to do a good job of anticipating the difference between desired communications and annoying SPAM.

MMS Messaging. With Multi-Media Message Service (MMS) you are able to create what may be considered more appealing, but potentially more intrusive, communications. The key is to keep it relevant, have permission and deliver value in the communication. The mobile users who are willing to consume MMS messages from marketers tend to be power users and not ordinary consumers. Target carefully based on user profiles.

Close Range Marketing. Bluetooth Wireless presents an opportunity for proximity based marketing. Due to the extremely short range of Bluetooth, this type of advertising is highly targeted. Bluetooth servers that sense the mobile device and size will be able to send messages in the right size and format.

 QR Codes. QR codes provide a convenient way to tie hard copy advertising to mobile marketing. The question is whether it is really worth trying to engage people in mobile marketing with other forms of expensive media. We’ve all heard of what works and what’s worse with QR codes. QR codes on subway signs where there is no cell service and in-flight magazines where phones aren’t allowed aren’t going to send your response rates skyrocketing. But in the right location and with an appealing utility to the ad, such as a reorder QR on a pizza box coupon, this can be an effective medium.

Voice Broadcasting. Let’s not forget that smartphones are phones. They can receive calls and store voice messages. Voice broadcasting to cell phones can be location based, incorporate IVR interaction and be linked to a call center.

What works and what’s worse? Effective mobile apps and mobile sites are key to any mCommerce and mobile marketing strategy. Use other methods judiciously based on your target user profile, the usage context and an alert eye to emerging trends.

 Glenn Johnson is a Senior Vice President at Magic Software Americas and frequent commentator on multimedia, mobile, eCommerce, social and enterprise systems.