The App development blog of Simon Monk, CTO of Meme IDE the cross platform development tool for Android, WM and IOS apps. free download from www.memeide.com

Tuesday 20 September 2011

Meme IDE: Sketch Box in v1.13

Version 1.13 of the Meme IDE includes this exciting new feature -- Sketch Box.


This feature can be used to capture signatures drawn on the touch screen with your finger or for annotating existing images.


Android devices generally have a capacitive touch screen that requires the use of a finger or a stubby stylus. As such they require a different approach to signature capture. In particular, they need the whole screen in landscape mode in order to draw a signature by finger.




For this reason, Android has a Sketch Box function rather than a Signature control. The Sketch box is launched by a function call and has a predefined screen layout, with additional options to clear the drawing, accept or reject the drawing. I use the word 'drawing' to indicate that the Sketch Box is useful for more than just capturing a signature.


sketchBox
sketchBox(image, titleText, data, callback);
The first argument is a reference to an image resource that must be added to the resources area of the project. If this is provided then it will be displayed as a background on which annotations can be made. The image must be copied into the resources folder of the project organizer and then a reference to it should be set as a File resource entry.



If you do not require a background image then the para- meter value should be an empty string.
The second argument is the title text that should appear above the signature area.

The third argument will be the initial data for the starting data for the sketch. If this contains the appropriate base64 string then the Sketch Box will contain this initial vector image. Note that this will not be modified, but rather when the callback is invoked (the final argument) then the new vector data will be provided as its argument.
The button labels can be modified by changing the re- source properties.



Similarly, the drawing color for the sketch box is also set using a color resource.
The following example shows a simple call to sketchBox and the corresponding callback function.

function sketchbox_open() 
{
  sketchBox("", "Sign below", data, "sketchComplete");
}

function sketchComplete(encoding : String) 
{
  if (encoding <> "") 
  {
    data = encoding;
  }
}

This example is typical because it saves the encoding that is received in the callback into the global variable 'data' from which the original vector image was fetched.


Decoding Sketch Book Files
The Signature control and the Sketch Box both encode signatures in an efficient vector format that is base 64 encoded. These signature strings are typically about 500 characters in length.
To decode these strings into jpeg (or other formats), a Java utility is available. Please contact support@memeapps.com if you find yourself needing to use this.

for more information on 1.13 check the release notes in our forum

Si.

Friday 16 September 2011

The Global Developer Challenge is open


The challenge is for developers to create and build a business utility application using Meme IDE. The developer of the winning app will receive a Panasonic Toughbook tablet. Worth over $2,000.

Build any form of business app through Meme IDE. That is the only specific requirement the rest is up to you, the submissions could really be anything from an expenses recording app, a to-do list app or even a currency converter but we really just want to see with what you can come up with. We are looking to reward development innovation from the Meme IDE beta community to stretch the capabilities of our software.

there is much more information and the entry details here

And I'm one of the judges!

Si

Tuesday 13 September 2011

Is Android a Good Platform for 'Grimy' Business Solutions?

Business solutions can be divided into two on the basis of the type of user.

There are 'shiny' business solutions for sales people and managers. These are essentially extensions to an organisation's CRM system. These solutions will generally also include email facilities and may be delivered on a Blackberry or an iPhone or smart Android device, in other-words a consumer-style smartphone.

A quite different type of solution, but one that is generally higher value in per-user revenue is the 'grimy' business solution. This will usually be delivered on a rugged brick of a phone. The end users may be involved in field service activities (fixing things) or delivery activities.



The devices and app will be heavily locked down and the workflow will dictate the activities of the engineer or delivery worker.

The vast majority of 'grimy' apps are written in Windows Mobile. In fact, we can be more specific than that, because the rugged equipment manufacturers have stated that they will be sticking with WM6.5 for the foreseeable future and not migrating to Microsoft's latest mobile operating system. Windows Mobile (and even more aggressively WP7) has long been negatively viewed by reviewers and blogs such as this one from Greg Kumparak @techcrunch but still it is used and heavily relied upon in business.

So, back to the original question. Where does Android sit in all this?

My answer is that Android is well suited to this kind of app for the following reasons:

* Hardware compatibility. The hardware currently used by manufacturers of rugged WM devices is in most cases perfectly capable of taking Android, without modification.

* The long screen. Screen designs for WM6.5 business apps tend to get very tightly packed. Scrolling the whole screen does not work well, when you have an app out in the field and you are trying hit the 10 pixel wide scroll area on a badly calibrated touch screen. In Android, it is far more natural to have a 'long' widely-spaced screen that the user can wiz up and down with using swipes of the finger.

* End-user familiarity. WM6.5 has its roots in consumer phone technology. But this is a fast moving technology and people are used to the iPhone / Android style of doing things. It is becoming more and more familiar to end users.

* No stylus. Businesses buy styluses by the box full. They get lost and broken with great regularity.

* Tablet-tability. The increasing abilities of android tablets and especially rugged versions are making them a more appealing option for businesses. Some good and more viable examples were highlighted by Matt Burns over at Techcrunch back in April.


When will we see 'grimy' Android apps?

Well, they are starting to emerge, but it will probably be at least two years before they are on a par with WM6.5 solutions - at least in the 'grimy' market.

It will be interesting to see if this is hastened by Google's purchase of Motorola's phone division.

Si

Find me on twitter @theappmonk

Friday 9 September 2011

Next webinar...

Thanks to those who attended my webinar yesterday. 

The next one coming up is next Thursday 15th Sept 09:00 PST / 17:00 GMT

(can you see a pattern emerging?) 

details and registrations for these free webinars are here.

We have put a list of dates together now so just pick any of them when you are free.

Si

Tuesday 6 September 2011

Requirements Engineering for Business Apps


The boundary between the customer and the developer is often a dangerous place to live. Customers think they know what they want and developers usually know what they think the customer needs. As with all areas of software development, success will only become possible when these views converge. Lack of convergence will result in disappointment at best and litigation at worst.

While this is not a problem that is confined to mobile development, it can be worse than a conventional system for a number of reasons:

* Mobile Apps are a "new thing" and customers often don't understand the design constraints and possibilities of a mobile phone platform.

* There is almost a status symbol value to having an App for you business. Even if there is no immediate operational need for such an application.

As with any situation where there is an expectations gap to be filled, communication is the solution. There needs to be a common understanding established between the customer and the developer. N.B. I use the developer in the sense of the consultant or analyst / programmer who will be responsible for developing the system. To my mind, creating another unnecessary information gap by separating the roles of analyst and developer is a recipe for disaster and contrary to the agile practices that we use internally to accomplish the development, once the requirements have been gathered. Yes, ideally requirements should be more fluid than that, but in practice customers will rarely be willing to accept an open-ended truly agile process, so we keep most of the agility internal.

Some of these points have been were picked up in an insigtful blog post by Brian Sommer over @ZDnet explaining how the requirements for business apps should be rethought to keep up with users.

We have a couple of techniques that we apply during our requirements gathering.

The first of these is about the customer teaching the developer and the second reverses the information flow and - ideally - bridges the information gap, to initiate a successful project.


'A day in the Life of'
The first of these is about the developer learning more about the current business process, and where the customer sees the mobile extension of their business occurring. The day of one of the workers using the app is spread out in a timeline, by attaching sticky-notes to a wall or whiteboard. Other contributory parts of the business are also mapped onto this diagram.

It is essential that someone who either does the job, or has done the job of the person holding the phone is present.

At the end of this kind of workshop, the developer will have a good understanding of the customer's business and be buzzing with ideas and thoughts about how to create a great solution. The customer will probably also have a better picture of their business process and also ready for the next step.

'App Workflow White-boarding'

The next step is for the developer to start drawing the App. This should not be pre-planned. It should be created in the presence of the customer with immediate feedback from them. The developer should keep control of the whiteboard pen but consult the customers, presenting their vision of the App in the form of a whiteboard workflow.

The app should support the mobile worker, not make their life more difficult. It should lead them naturally through their daily tasks in a linear manner. Modeless user interfaces where you jump around between screens and the user controls the workflow in their head are rare. As such, it is the operational people in the room who should have most influence. Hopefully they will be wowed by your insights and pleased to contribute.

Customers tend to want the App to do more than it needs to. The App development should be phased, so that each phase can inform the design of the next. The first phase should be as simple as possible.

There is of course much more to requirements engineering for mobile Apps, but I hope these techniques will give you a good start.




Monday 5 September 2011

Free Webinar


Simon Monk our CTO (aka theappmonk) will host an open discussion around any issues you want raised involving Meme IDE™, its use and  the future development plans.

The third webinar will start at 09:00 PST/17:00 GMT
on Thursday 8th of September 2011.

If you plan to attend the webinar please just drop your email to webinar@memeapps.com so that we can send you out the Adobe Connect link.

DISCOVER HOW TO…

BUILD using our effortless development environment, Meme IDE™. Through its user friendly drag and drop editor for both WM and Android.

DEVELOP complex functions using the unique MemeScript™. A language created to make elements simple and cohesive on any platform.

Last week we held the first of our webinar sessions and this is second chance to catch it and speak to Simon Monk, the creator of Meme IDE. We are fully open to any questions, bugs/fixes you want highlighted, any future platform targets and features you want discussed. This is your opportunity to have input into the development.

We would appreciate your questions prior to the event so we can prepare for them, post here or below.

If you just want to drop in, feel free to sit back and view the webinar as it happens; learning about Meme IDE™, the thinking behind it, the specific technical details and where we are planning on heading. But please let us know so we can send you the link.

You can find Simon on twitter or @memestreams for more information

As we have said this is a community based beta and we want to here what you have to say!

email webinar@memeapps.com to join

Friday 2 September 2011

Standards in Mobile Development

When will mobile operating systems achieve a universal development platform?

The generally accepted answer to this question by seasoned developers is around the same time that Windows 7 and OS X become open source. There is far too much technological pride and 'not invented here' syndrome floating around for that to happen any time soon. In any case, excessive standards can stifle innovation.

HTML5 offers such a promise, but the standard is immature and Microsoft is still basing its Windows Phone development on Silverlight. Kevin C. Tofel at Gigaom highlighted some telling stats In any case, many suppliers of the rugged phones that are still the mainstay of business solutions are resolutely sticking with Windows Mobile 6.5.


Developers that I speak to have doubts about writing full featured apps using web technologies. Javascript is still trying to shake off its 'script-kiddie' reputation. For some developers, the only acceptable way to write a mobile app is to use native development tools.

If the desirability for standards across mobile platforms is largely motivated by the desire to simplify the process of creating cross-platform apps. then maybe this same goal can be addressed, not by standardizing all platforms, but creating an application development layer that sits above the native development tools generating native projects that are then compiled by the platform specific tools.

Meme IDE is such a tool. It has platform specific screen designers and a platform neutral programming language (Meme Script). The platform currently generates native code projects for Windows Mobile 6.5 and Android 2.1, with iOS and Blackberry on the way.

Something to think about!

Simon Monk    @theappmonk


kick it on DotNetKicks.com

Thursday 1 September 2011

Meme IDE SQLite Database Interface

Simon Monk CTO of Meme IDE
 Today's release of Meme IDE 1.12.0 will include an Interface to the SQLite database bundled with Android.

We ended up with what we believe is a simple but powerful interface that just adds three new library functions to Meme Script.

To put this into context, Meme Script already has the store and retrieve commands that will persist small amounts of data contained in a variable by serialising it. However, for some applications, that is not enough and you need a proper database.

On a mobile app, databases do not tend to have a complex schema. A typical example might be of a parts database for a service engineer. There may only be one or two tables, but they might contain a few thousand records. It is quite likely that an app would be deployed with an initial database, to which occasional incremental updates would be applied.

In my experience, such apps are far more about reading of data than writing of data. As such it is important to have the ability to perform ad hoc queries in the form of SELECT statements to retrieve data, as well as operations to modify the database and efficiently bulk-load a database.

Since the Meme IDE has a user interface for defining record structures, it is important that when we run a query against the database we can put the resultant data into record structures that we have previously defined.

In our design session for Meme IDE's database interface, we explored a number of options including complex Meme Record / SQL table mapping as well as various complex functions for manipulating the data in record form. Eventually, we ditched it all in favour of what we think is the simple and elegant interface described below:


sqlScript(databaseName:String, sql:String) : void


The first function is intended for bulk loading of a database with data. The first argument is the name of the database. If the database does not exist yet, then it will be created. The string containing SQL can contain any valid SQL that is then loaded up into the database. For instance, the string would typically contain a series of table creation commands followed by a whole load of insert commands.

Typically the SQL supplied will be in an embedded file in the app that can be read using retrieve or fetched using a web request.



sqlQuery(databaseName:String, sql:String) : [](Record)


The sqlQuery function performs an SQL query on the database. This should be a SELECT statement. The sqlQuery function should always be called in an assignment. For example:


var contacts : Person[];
contacts = sqlQuery("mydatabase", "select name, tel from person");

This allows the Meme Script compiler to establish the mapping between the Meme Script record and the SQL table being used.

The mapping of field names between record and database table is by name. So in the example above, if 


the record has attributes of name and tel then these will automatically get populated.

For indirect mappings, you can use the SQL AS keyword, for example:


var contacts : Person[];
contacts = sqlQuery("mydatabase", "select name, tel AS telephone from person");




sqlExecute(databaseName:String, sql:String) : Integer

The final database function is intended for use in modifying the data. The SQL will typically be an INSERT, DELETE or UPDATE command. 

The Integer result will depend on the operation. 
For an INSERT, the return value will be the ID or the new row inserted.
For a UPDATE or DELETE will be 0 for success or -1 for failure. This should really be the number of records modified, by unfortunately SQLite does not support this.

That concludes this blog entry. It just remains to say that there will be an example app and further information made available shortly after the release.

We always welcome any comments or ideas for improvement.
Find me on twitter @theappmonk
kick it on DotNetKicks.com