Planning a mobile financial application

Posted on May 17, 2012 by

Image

Which platforms should you support for a mobile financial application?

One of the most exciting areas in the mobile space is the financial application. Mobile devices are very personal, and naturally people want to use them to control their own personal finances. So if you’re in the retail financial world, you’ll want to provide mobile application support for your services. Penrillian specialise in developing such applications, and we’re familiar with some of the questions and answers you may have.

So let’s suppose you’re creating an application to provide financial account management and online payments. Your first question is key to making the project a success: What devices should you support?  Ideally of course, the answer is all of them; but in practice, unless you’ve unlimited time, resources and money, you’ll have to prioritise, and support some mobile platforms before others.

There are four major smartphone platforms to consider currently: Apple’s iOS; Google’s Android; Microsoft’s Windows Phone; and RIM’s BlackBerry. In terms of the number of smartphone handsets (in the UK), typically currently Android leads, followed by BlackBerry, then iOS, and lastly Windows Phone. However there are other important considerations:

Will people with smartphones be willing to use this type of app? Android users tend to be willing to download free applications, while iOS users are more willing to pay for apps. BlackBerry users are less willing to download apps than either, and often expect them to be comparatively expensive. Windows Phone users are accustomed to not finding apps that are available for the other platforms, so they may be less app-enthusiastic. With a financial service application, you’ll be charging via transactions, so it’s very unlikely you’ll be charging for the app itself: All this points towards Android being the best platform to support first.

How will customers find the app? Apple’s App Store is fabulously successful; Google’s Play Store is huge too. But their size is sometimes disadvantageous when it comes to marketing an app and ensuring it stands out. People are more likely to find apps produced for the smaller BlackBerry or Windows Phone stores. For a financial service application, these are generally less important considerations, as you’ll have other ways of publicising your app: Email, text, your own website, other types of online marketing, and even direct mail. With all four platforms you’ll be able to create links that direct users’ devices to online locations from which the app can be downloaded.

Will the app be able to do what you want?  iOS and Windows Phone are very tightly locked down: They both have a model where only one app runs at a time; with only limited processing possible for apps in the background, and no background processing for an app at all between the phone being restarted and the user first running the app. That makes iOS and Windows Phone unsuitable for some kinds of applications. However, all four platforms have mechanisms for sending notifications to a user, even when the app isn’t running – and that’s about the only complex thing a financial account management application will need. If you want your app to support NFC payments, though, your options are much more limited: Only a very few Android and BlackBerry models have the hardware to support NFC; iPhones and Windows Phone mobiles don’t as yet.

How easy will it be to develop the app? It’s easy to develop software for both iOS and Android; there are good environments, excellent documentation and myriads of forums discussing any technical problem that might be encountered.  Windows Phone has the good environments and documentation, but not yet the forums; and BlackBerry lags a little on all three counts. There is another option though, a single environment shared by all four platforms – the web browser. With browsers supporting HTML5, it’s becoming practical to write applications with local storage and sophisticated user interfaces. JavaScript is a powerful development language, and libraries like JQuery paper over the cracks of the differences between browsers, making cross-platform development realistic. With frameworks like PhoneGap and Appcelerator we can even make a web application appear as a native application, and support notifications and other native features. Other libraries, such as Sencha Touch, can simulate the look and feel of each platform. The results are often excellent, but rarely as good as can be achieved with native code.

How good will your app be? We’ve all learned the lesson Apple taught us – usability is key!  It’s crucial that customers will want to try the app and then keep-on using it. That requires the most enchanting customer experience that can be achieved, and suggests a native implementation will be best, as opposed to a JavaScript solution.

To conclude, I think you’ll probably chose to support Android first, followed by iOS and BlackBerry, and only consider Windows Phone much later. Unless, of course, your market research, about your particular audience, leads you to a different decision.

Charles Weir – Penrillian

Posted in Apps, Mobile, Operating Systems | Leave a comment

Windows 8: Platform v Product

Posted on May 3, 2012 by

There are few truly defining moments in the lifecycle of a long-running software product. Many don’t undergo major usability changes. For example, the Apache http server project has been in use for seven years and, as many SysAdmins will testify, although the code has changed significantly, the user experience has remained virtually the same. Similarly, from a usability perspective, Twitter has changed little over the years.

Good cross-platform software design is the hallmark of an excellent product. This constancy lets users repurpose the product for their own uses; though perhaps rarely as extreme as this case of a washing machine that’s made to Tweet when its cycle is complete.

But there can be teething troubles when creating a truly cross-platform product, especially if it’s the world’s most popular operating system, and you are trying to unify mobile and desktop platforms with a common approach.

I am, of course, talking about Windows 8.

Developers worldwide need to ensure that their current products are compatible with this latest Microsoft operating system. A long testing cycle began with the Developer Preview of Windows 8, and has continued with the Consumer Preview. One thing that has become blazingly apparent in using Windows 8, is that it is a total paradigm shift for desktop.

And what better example of this major overhaul than the absence of the iconic Start Menu? Since Windows 95, ‘Start’ has been the central feature of Windows. Even the power user, that legendary, hard to please complainaholic, is hardwired into it. The Start Menu is the gateway to everything in Windows. It is so central to the operating system that almost all non-Mac keyboards in the world have a ‘Windows Key’ (Linux users read: ‘Meta Key’). In both Gnome and KDE, the windowing systems that comprise 98% of all Linux desktop installations, the Meta Key maps to the main menu – in both cases a Start Menu clone. Until now, Windows has been the utmost example of platform-software interdependence.

With the rise of smartphones, tablets, touch screens and apps, the dominance of the desktop PC looks like drawing to a close: Obsolescence is looming on the horizon in some situations. And now, in a brave move, Microsoft has decided the time has come to unify mobile and desktop platforms – to make the whole leap from a desktop-centric operating system to a mobile-style OS. Will this prove to be a resounding success, or a premature shift? Mobile still only holds 7.2% of the global OS market share, and in business the desktop is still the clear market leader. There is no doubt that desktop and mobile platforms are converging, and will eventually be unified, but have Microsoft leapt into this uncharted territory too soon? The market will have the last say.

Although almost all the features of the Start Menu are available in the new Metro-style interface, and it could be argued that Metro deniers are asking for ‘a thin metal ruler’, when making a massive change to an existing product you must be sure that the timing is right.

At Penrillian, cross-platform development is our specialty: Providing a consistent experience for all users is our bottom line. Acceptance testing is crucial to any product, and the feedback of users is one of the most important facets of the development cycle. If the customer is not happy, it is essential to change. It is important to understand fully the platform your product runs on, and to integrate seamlessly with it, instead of being at odds with it. Windows 8 will be a lesson to us all … that cross-platform development is one of the most difficult things to do well, and that it is best for a product to work with a platform, not against it.

Posted in Uncategorized | Leave a comment

The Abstraction Layer Is King

Posted on February 27, 2012 by

As developers, a lot of the time we find ourselves writing code for other developers to use. Creating APIs which help other developers create good software quickly and with minimum pain. The abstraction layers we create combine to produce simple solutions to complex problems in a short space of time. One bad apple can spoil the whole barrel, and one poor API can kill an entire product.

So, the importance of taking the time to think carefully about the interfaces our APIs will provide, and how we intend to implement them, cannot be understated. If we make the wrong decisions we will force the people who use our software to make bad decisions and develop bad software. If we persist in making bad decisions, they’ll end up using a different API.

A good example: We have a method on an interface which provides a list of all the ethernet adapters on the local machine. When the API was first conceived the method was defined like this:

IList<INetworkAdapter> LocalEthernetAdapters();

This looks fine, until the time comes to implement the API. To implement this particular method we must make calls to unmanaged code to fetch a list of all attached hardware from Windows. We iterate through this list, wrap them in a wrapper class and yield return them. This is a very time consuming operation, and depending on the amount of hardware in the machine’s device tree, this can block the flow of execution for 20 seconds or more.

Even if we’re very clever and use LINQ to build an expression tree which will enumerate the list on demand we still end up having to perform an expensive call to ToList() in order to get a suitable data structure to return to the user.

Of course this could just go in as a known limitation of the API, but we want our solution to be as fast, responsive and non restrictive as possible. If a programmer comes along and decides to place a call to our function in a lock then they are in great danger of freezing their program. If they decide to only use the first element in the list and discard the rest then we’ve just wasted a lot of time enumerating the tree for nothing.

Suggested Solution:
A slight change to the interface gives us much more freedom in how we implement our API, and how other programmers use it.

IEnumerable<INetworkAdapter> LocalEthernetAdapters();

We can retain our original LINQ based implementation but we can avoid the expensive and time consuming call to ToList(). Instead we are passing out an expression tree which will let the user enumerate the collection in their own time. If they only use the first element then they’ve only spent as much time as it takes to find the first valid device and wrap it, if they want to perform more queries on top of our original selection they can continue to extend the expression tree, trusting that the CLR will provide the fastest solution it can in the circumstances.

In short, we’ve retained our business logic, which we know was correct, but we’ve cleared ourselves of the responsibility of deciding how the user should use our product, and how the underlying software should provide it. In modern computing the abstraction layer is king and by making each layer as lightweight and non-restrictive as possible we can build complex and feature rich software without incurring heavy performance penalties. The better decisions we make defining our interfaces, the freer we are to provide elegant solutions to difficult problems.

Pete Martin, Junior Developer, Penrillian

Posted in Uncategorized | Leave a comment

Look Before You Leap

Posted on February 7, 2012 by

As developers, when we begin to work on a solution, some of our most critical decisions involve selecting the most appropriate language and development environment. With the right tools for the job, developing can be painless and stress-free.

Conversely, rushing-in and choosing the wrong tools is likely to lead to complications and difficulties further down the line. For new developers this is a common and understandable mistake. As a young coder, and before moving to Penrillian, I was part of a team that was charged with producing a cloud-based medical surgery management system with a web front end. At the start of the project, being eager to get our hands dirty with the actual code, we rushed through the design and architecture phase. Within a couple of months we had a hulking, inefficient codebase that had become so complex that it was almost unworkable. We had to make a very tough decision: Either we could continue to work with our current implementation, and hope (desperately) that we could meet the deadline and the functional requirements adequately; or we could take a week off coding to review our methodology and see if we could come up with a better solution.

The second option, as it turned out, was the best. After a week’s retrospective activity and research into alternative approaches, we had a much clearer idea of what the requirements demanded, and we had identified a set of tools that would help us to meet them. Within another two weeks we had surpassed our achievements of the previous two months, and we had a better framework that enabled rapid progress.

The story had a happy ending as we completed the project on time, fulfilling all of the objectives. Equally importantly, the experience was a valuable lesson: Rushing into any project without knowing that the tools you have chosen to work with are the best tools for the job, is asking for trouble. Always consider the old adage “look before you leap”:  Unlike being a (reckless) player in platform gaming, the stakes in programming can be astronomical.

This is a lesson that only experience can truly impart, but the next time you are developing ask yourself this … If you aren’t 100% confident that the tools/environment/platform you have chosen are the best for your needs, then how can you be truly confident that your solution is the best it possibly can be?

In a future post I’ll explore some examples of bringing more finesse to the start of a development process.

Pete Martin, Junior Developer, Penrillian

Posted in Uncategorized | Tagged , | Leave a comment

Does obscure code compromise security?

Posted on January 16, 2012 by

A long time ago, as a consultant to Symbian, I remember proposing an improvement to the Symbian OS to make it easier for developers to understand and program. A Symbian product manager opposed the change in an informal discussion, suggesting that if Symbian code was easier to understand it would ruin the security of the OS!

Though that was (I hope) a joke, it represents a common misunderstanding of what software security is all about. If your security depends on obscurity, on attackers not understanding your code, then, quite simply, it’s not secure. For you can never be sure that there won’t be some someone who reverse-engineers it, gets spies to copy the source code, or simply attacks in an unexpected way. For no matter how trustworthy your programmers may be, anyone can make a mistake and perhaps leave a security ‘loophole’; and if the code is difficult to understand, then others of your team won’t find the loophole. And once anyone finds it, your security is gone.

True software security depends on clarity, and simplicity. Many encryption algorithms turn out to be based on surprisingly simple mathematical transformations. Why? Because that means that the egghead mathematicians who study such things can prove – yes, really prove – just how difficult the algorithm will be to break.

Of course the security of an application depends on much more than encryption algorithms. Applications may have thousands of lines of code, and it’s rarely possible or economically viable to do any kind of mathematical analysis on the code. So how do we implement security for them?

Again, trustworthy programmers can only be part of the answer. Instead we look to the world of accountancy; a key role of any accountant is to look for fraud. Indeed accountants are notorious for nit-picking precisely because it’s small discrepancies that often show up where something’s seriously wrong. The equivalent in software is the security audit: security specialists audit the source code for security loopholes.

Security audits have serious implications for the developers of code. Just as accountants need the accounts they review to be properly organised and set up so they can easily check for fraud; so software security specialists need the code they analyse to be comprehensible and easily navigable, so they can easily find and check for security issues. And just as accountants expect and enforce accountancy hygiene factors, such as consistent bookkeeping, so software auditors will expect and enforce similar hygiene factors in code: validation of inputs, design to handle typical kinds of software ‘attack’.

So the primary things we need for secure code are clarity and good design. The code must be easy to read and review. It must make clear the intention of each component, method and line. And it must satisfy the basic hygiene factors consistent with good coding.

In short, secure code must be verifiable!

Charles Weir

Posted in Mobile, Software Development | Leave a comment

A Brighter Future for RIM?

Posted on January 3, 2012 by

RIM is an interesting company.  Two years ago they were the apparently unstoppable darling of the smartphone market.  Now they’re receiving a battering in the media, and facing a rapidly shrinking market share with hugely powerful competition.  So what will they do next?

Let’s look at three facts about RIM and see where they lead us.

1.       More than 50% of RIM’s current market started as a happy accident.  RIM designed their range of inexpensive phones and their cloud-based BlackBerry Messaging service to suit businesses, and found they exactly suited the teenage market.  But as they are now learning, this market is extremely fickle, and is easily seduced by the rival claims of Android, iPhone or Windows Phone.

2.       RIM’s BlackBerry OS operating system has reached the end of its life.  Yet RIM’s current strategy – of adopting a POSIX based environment with open source support – looks rather like Nokia’s strategy of three years ago, which proved disastrous.  Can RIM be more successful?

3.       RIM’s core business is providing handset security to IS departments.  This was the original strength, and this is what suits their company culture best.  Their BES commands trust from IS departments internationally and supports all the features they need most: full end-to-end encryption, push features, total device management control.

Indeed, in a world that’s seen few innovative handset features for over a year, we’ve been really impressed by RIM’s new BlackBerry Balance feature, which allows users to have business and home applications on the same phone without compromising the security of the business applications; even cut and paste is regulated.   If RIM improve their Android support to support mass-market home applications, that’s a compelling proposition.

So what will RIM do?

We believe RIM will return to their core business: business IS.  We fear they’ll probably continue to struggle in the consumer market, and may need to rationalise some operations and structure, though BlackBerry Messaging will still remain compelling in markets where network data tariffs are high.  We suspect market forces will drive RIM to support ‘native’ Android applications as well as those converted specifically for the platform, thereby avoiding the problems that beset Nokia.

In the business market, RIM has a commanding value proposition.  By updating the BES infrastructure, and by supporting iOS, Android and Microsoft phones with the BlackBerry’s e-mail and security propositions, they can remain the IS mobile vendor of choice for a huge number of companies.    Which is exactly what they are doing: updating infrastructure, and supporting other manufacturers’ phones.

And there’s loads of profit in that.

Charles Weir

Posted in Mobile | Leave a comment

Programmer and Toolmaker

Posted on December 5, 2011 by

Almost all the programs written at Penrillian are tools.  They’re not an end in themselves; they allow us as users to achieve other things.  Business tools allow us to communicate, to coordinate, to calculate; connectivity tools help hardware to behave as we want; messaging tools allow us to communicate better with our friends.  Video players or screen readers help us access the content we want.   In fact, probably, the only programs that aren’t classifiable as tools are those that are an end in themselves: games.

So programmers are inherently toolmakers.  That is their vocation.  And good programmers tend to be those who think in terms of tools, who work with existing tools to make them better, and who construct tools to solve the problems that existing tools don’t handle.

Some of these tools are conceptual: methodologies, processes, algorithms.  Others are practical and very real: scripts to tackle repetitive tasks; plug-ins to frameworks and compilers to make the behaviour what’s required; and components to reuse in different situations.

Given a large repetitive task, such as implementing many similar screens, an indifferent programmer might repeat many times the work and code used for the first screen.  A good programmer will think in terms of constructing tools to reduce the amount of work involved: maybe a micro framework to make it all simpler, maybe some kind of parser to generate the code required, or simply components to reuse in each screen.  The good programmer’s solution will typically be better in terms of cost and time to market: it reduces the time to produce the work, and reduces the long-term maintenance costs.

Good programmers are also tool users.  Given a problem, they will be able to suggest not one but many possible approaches, each using a different conceptual tool.  Selecting the set of tools used to solve the various problems in a software project is often the most critical decision made in the project.  Effectively it is setting up the toolkit for the project.  Once again the programmer is making tools.

So good programmers are toolmakers.

Charles Weir

Posted in Mobile, Software Development | Leave a comment