Android Development – Desirable Apps

Click Here to Request a FREE Quote to Develop an iPhone App or Android App

AVG Android App Performance Report Q4 2014

Posted by Eric Worrall on March 2, 2015 in Android App, Android Development, Mobile App 0 Comment

AVG Technologies has published a list of popular Android apps, which significantly impact your mobile phone’s battery life, network usage and data storage – apps which they recommend users should avoid.

The top spots were secured by Boom Beach and Deer Hunter 2014, both interactive high powered action adventure games.

Second on the list is Spotify, the digital music streaming app.

AVG technologies also mentions that previous winning resource hogs, Puzzle and Dragons and FarmVille, have both suffered significant declines in use, since being named in AVG’s previous report.

What does this mean for your Android App Project?

First, anyone who fires up a copy of Boom Beach or Deer Hunter 2014, should expect their mobile phone’s battery charge to plummet.

Android phones and iPhones are severely resource constrained devices. To maintain battery charge as long as possible, mobile app developers (both iPhone App Developers and Android App Developers) are encouraged to develop mobile apps in such a way as to allow the mobile phone to subtly switch itself off, whenever possible.

With an action game this simply isn’t possible – games are always doing something.

Some of the other apps on the list though are likely to catch users unaware. For example, who would expect that listening to a little music, using Spotify, would kill their battery and exhaust network bandwidth allowance?

The real surprise on the list though is the Facebook App. According to AVG, Facebook is one of the worst offenders, when it comes to chewing up your phone’s battery, storage and network capacity, even when you aren’t actually using the app. This is a serious criticism – I suspect the Facebook team will have no choice but to respond.

How do I avoid having my Android App Development appear on AVG’s list?

My advice is simple – if your mobile app has to do something which uses a lot of battery life, storage, or network bandwidth, TELL the USER. If a mobile game app had a small warning, recommending users plug the phone into the charger while playing the game – is this such a bad thing? You are just taking care of your user.

And if you mobile app is eating a lot of battery, network or storage, and there is no clear reason why this is happening, ask your developer to review the app, demand a clear explanation. There might be a reason – or it could actually be a defect. Sometimes mobile apps which are defective sit there burning computation effort, for no good reason.

If you would like advice on how not to end up on the AVG list, or are not receiving the clarity you want, when you communicate your concerns to your current developers, please contact me.

Rapid Geosearch for Mobile App Developers

Posted by Eric Worrall on February 23, 2015 in Android App, Android Development, iPhone App, iPhone Development 0 Comment

Geosearching a large database of places, for places which are near your current location, is a surprisingly wicked theoretical problem, especially for mobile app developers. Understanding the problem, and how the solution works, has important applications which go well beyond geosearch.

The difficulty is the search is two dimensional. To find a set of places which are near your current location, you have to match both latitude and longitude. But there is no relationship between latitude and longitude. You cannot infer a longitude, if you have the latitude, they are separate entities. Latitude and longitude are independent search criteria.

Why independent search criteria are a challenge

Say you want to find all places which are within a kilometre of your current location. Given your current location, you can easily convert a latitude into a range of values which is roughly a kilometre wide. Similarly you can convert a longitude into a range of values which is roughly a kilometre wide. But this is where the trouble starts.

Once you have your strip of land, you can search for places within that strip which are also within the range of longitudes you want. But consider what that strip of land you just requested actually represents; if you ask the database for all results within a range of latitude values, what you are actually asking for is all of the locations within a strip of land which encircles the entire world.

If your database contains millions of places, and you ask your database to return all the places within a world encompassing strip of land, your intermediate search result may contain many thousands of candidate places. If you started with latitude, filtering this long list of latitude candidates, for places which are also within the desired longitude range, can place impractical demands on your database’s computation capability – particularly if you are using a mobile device to perform the search.

Searching Latitude and Longitude, for nearby places.

Performing a traditional search, where you start with the first search criterion (the latitude), then refine the search using the second criterion (the longitude), is clearly very inefficient. What we need is a method of filtering the list, which allows us to efficiently apply both latitude and longitude to our search simultaneously.

R-Tree – A search which applies multiple criteria simultaneously

The secret of R-Tree is that it divides the problem domain into a series of concentric boxes. Each box contains smaller boxes, until at the end of the search, the last “branch” of the “tree”, the final box contains the results you want.

Even though the top level outer boxes contain thousands of results, the mobile app does not have to look at all of these results – all the mobile app sees is a manageable series of boxes. Searching the boxes is like opening a set of Russian dolls, one inside the other. The final results of your search, the results which the mobile app needs to display, are inside the innermost box.

Most importantly, defining the search algorithm as opening a series of concentric boxes, each box closer to the results you want, means you are applying both indices, latitude and longitude, simultaneously – which allows much more efficient filtering of results, than would be the case with searching latitude and longitude independently (world encompassing strips of land).

R-Tree search divides the problem in a series of concentric boxes. — R-Tree search divides the problem into a series of concentric boxes.

R-Tree your next mobile app development project!

The best part of R-Tree search is that it is fully supported by sqlite, which in turn is fully supported by the iPhone App Development and Android App Development environments.

You do not have to build the concentric index boxes yourself, the Sqlite R-Tree package will take care of the technical details of building and maintaining an efficient R-Tree index to your places data. All you have to do is specify which fields should be part of the R-tree search index (in this case, the fields you want are latitude and longitude).

If you wish to develop an Android App or iPhone App, which requires blinding fast geosearch, or if you have an esoteric data search problem which just doesn’t seem to be responding to normal database performance tuning, consider R-Tree – it might be the solution you need.

And of course, R-Tree is also well supported by server technology – so you can, if you choose, perform blinding fast geosearches using a server call, rather than embedding the data in your mobile app.

If you would like to know more about R-tree, and multiple independent database index search techniques and tricks, contact me for more information.

Google plan to subsidise Android App Developers

Posted by Eric Worrall on February 15, 2015 in Android App, Android Development 0 Comment

Google Android App Developer Mobile Data Usage Subsidy

Android Authority News reports that Google Corporation is in talks with some Android App Developers to subsidise mobile app data costs in the third world, to help promote mobile app usage in countries with high data costs.

Google may be on the verge of breaking into developing markets with their cheap Android One handsets, but there seems to be a problem stifling many smartphone users in those specific countries. According to data from McKinsey and the International Labour Organization, a Jana survey of 8,000 smartphone users found that data expenses were among one of the biggest reasons why users don’t download or use applications on their smartphones. Specifically, over 25% of respondents of the survey from India, Indonesia, Thailand, Egypt and the Philippines considered high data costs to be the biggest obstacle holding them back from using apps. Google’s Android One platform might offer low-cost devices to emerging markets, but that doesn’t help the high prices of data costs at all.

According to a new report from The Information, Google may be looking for ways to subsidize data costs so users can actually use their smartphones. Google engineers have reportedly been in talks with app developers in emerging markets to reduce or even completely eliminate mobile data costs using a practice called “zero rating.” Zero rating is nothing new in the mobile world. It’s basically a way for app developers, such as Facebook or WhatsApp, to strike deals between wireless carriers to subsidize data costs, which can then be promoted by both the app developers and the carriers involved.

So where does Google come in? According to “sources familiar with the matter,” Google has plans to pilot this initiative in India with notable services like Flipkart, Snapdeal, Redbus and even Ola Cabs, India’s version of Uber. These services tend to rack up much more data than users are allotted per month, so the developers are already willing to pay the high bandwidth costs to get more users connected with their services. These are obviously the first apps and services Google is targeting with their initiative – companies that already practice the subsidization of data – to bring more users online.

Acting as the middleman would allow app developers to not have to make these zero-rating arrangements with individual carriers.

Read More…

Data Usage – the hidden roadblock to mobile app uptake?

The fact that data costs are a major roadblock for app usage in the third world is something all Android App Developers and iPhone App Developers should consider when creating new apps, but it is not just third world mobile app users who have this problem. As developers we take our mobile apps seriously, they are a big part of our lives – so we often purchase top flight mobile plans with generous data allowances. It is easy to forget that not everyone has this kind of budget for their mobile data access – that many data access plans, particularly outside the USA, are expensive and restrictive.

Mobile data usage is also a serious issue for tourists visiting from overseas, some overseas roaming data plans charge $4 / Mb of data or more. In today’s data hungry world, this can easily lead to tourists inadvertently incurring hundreds of dollars of unwanted mobile data usage fees.

Some low end mobile plans, even in countries like Australia, and parts of Europe (in fact pretty nearly every country except America) can sometimes include tiny mobile data allowances, which are rapidly exhausted by normal mobile app usage – either forcing mobile app users to start consuming expensive excess data, or leading to mobile data access being switched off.

Even on a higher level mobile app data usage plans, I sometimes find myself switching off cellular data, to conserve bandwidth – Android mobiles and iPhone mobiles sometimes attempt to transfer ridiculous amounts of data over the mobile cellular network, particularly if mobile cloud services are active. Outside of the USA, ignoring cellular data access can be an expensive mistake.

Strategies for reducing mobile data usage

One of my clients recently suggested an innovative solution to this issue. Their iPhone App and Android App does not need immediate access to data, so the client requested that the mobile app be developed with the ability to pre-cache data – so that users could pre-load data via WIFI, to avoid large cellular network data transfers.

Altogether I think this issue should be taken as a real wakeup call – if you are designing a mobile app which potentially transfers significant amounts of data across the cellular network, it is well worth taking a little extra time to determine whether you can offer clients a way to minimise cellular traffic, either by offering an option to pre-load data via WIFI, or by offering a “minimal data” mode. Because for users in third world countries, sometimes even for users in first world countries, mobile data usage can be a real showstopper – it might make a real difference to the popularity of your mobile app in countries and scenarios, such as overseas roaming, where mobile data access is expensive.

Of course, you might be one of those lucky Android App Developers who received the offer from Google, to help subsidise use of your mobile app. Or this could become an option, if your Android App is popular, or attracts the attention of Google executives in some other way.

If you would like to discuss the mobile data usage of your mobile app idea, and strategies for minimising the impact of mobile data usage on mobile app users who might be constrained by an expensive cellular data plan, please contact me

A Freemium Mobile App Development backlash?

Posted by Eric Worrall on February 11, 2015 in Android App, Android Development, iPhone App, iPhone Development, Mobile App 0 Comment

A gathering backlash against some freemium mobile apps?

Freemium Mobile Apps – apps which are free to download, but which offer in-app purchases. A few days ago, I discussed different ways of monetising apps, and how the Freemium model appears to dominate the industry.

However there are signs of a potentially serious backlash against tactics some freemium mobile app developers are using, to encourage users to purchase in-game options.

According to Game Revolution

… The thing is, our industry has become bad; society’s view of our industry has become bad. We try to get as much money out of the player as possible. That’s what the job of the [casual] game designer has become. That’s how people see us.

…What we’re doing is selling games to children. I think it’s so disgusting. We sell them $100 packages of fake currency and make their parents pay because we can easily manipulate them. This is the thinking of the gambling industry.

Read More…

To put this into perspective, not every iPhone App project or Android App project which contains in-app purchases is “evil”. If you want to give people a taste of your app’s functionality, then it is entirely reasonable to present basic functionality in a free mobile app, then encourage people to purchase additional capabilities. For example, Angry Birds – you could play a few levels on the free version of the game, then you could buy the “full” version, then there was ONE in-app purchase option – the “great eagle”, which allowed you to blast through frustratingly difficult levels, to see the next level. Good clean fun – simple costs, you know what you are buying.

But clearly there is a line which it is dangerous to cross. If your app targets children – encourages them to spend ridiculous sums of real money buying food bricks for their pet dragon or walrus or whatever, so their faithful electronic companion doesn’t starve and die, to me this is a high risk strategy. There’s a real risk your mobile game might end up at the top of someone’s list of evil. Such a design might even trigger a consumer campaign to remove your product from app store or play store.

My advice is, everything in moderation. By all means throw in a few in-app purchases – its a fantastic way of boosting revenue. Who knows what apps we would never have known, without the financial incentive provided by profits from in-app purchase options.

If you would like to discuss app monetisation strategies, please feel free to get in touch.

Fast Text Searching in a Mobile App

Posted by Eric Worrall on February 10, 2015 in Android App, Android Development, iPhone App, iPhone Development, Mobile App 0 Comment

Searching large text fields (as in thousands of words) for small key phrases is traditionally a difficult problem, especially when the search has to be performed by a mobile app, using an Android or iPhone handset’s limited computing power.

Linear Text Search

Your mobile app could search for your key phrase by checking every letter in your text, as the possible starting point for the phrase you want to find. This works when the text you are searching is short – but if you are attempting to search many thousands of words of text, a linear search is slow, even at modern computing speeds.

Search: The quick brown fox jumps over the lazy dog Key Phrase: lazy dog Algorithm: check each letter The quick brown fox jumps over the lazy dog

Text Map Search

The alternative is to partially pre-run the search when developing the mobile app. You can’t predict the keywords a user will enter, but you can create a searchable text map of the relationships between words and phrases in the text to be searched, to allow code to rapidly search the map, rather than having to check every letter of every word of the text to be searched.

Search: The quick brown fox jumps over the lazy dog Key Phrase: lazy dog Algorithm: pre-run search L -> La -> Lazy -> Lazy Dog

How do you pre-run a search? You could research efficient word search structures – suffix trees, and other exotic data representations. After a significant amount of effort you would be able to create a search engine, which was much faster than a linear search of every letter in your text.

Or you could use the full text index feature of the SQLite database engine, which is fully supported in both the Android App and iPhone App environments.

SQLite Full Text Index

The SQLite full text index engine is very fast – correctly configured, it can search 10s of megabytes of text stored in your mobile app, fast enough so your code can update a list of hits in realtime, as the user types into the search box (obviously its a bit smoother if the database search is running in a different thread). In my experience the limitation on search speed is usually how quickly your code can create tables of data to represent the search results, rather than executing the search itself – so during performance tuning, it is worth considering minimum phrase lengths (e.g. don’t start the search until the user has entered at least 3-4 characters), to limit the number of results which are likely to be generated by a given search.

Creating a SQLite Full Text Index table is very similar to creating a normal database table. If the text to be searched is fixed (i.e. doesn’t change when the mobile app is used), the text search SQLite database can be created when the app is built, and accessed immediately, as soon as the user starts the mobile app.

Other Full Text Index Options

Full Text Index databases are also well supported by web technology. On most Linux boxes you can choose between a SQLite Full Text Search Database or a MySQL Full Text Search Database.

The Next Step

If you are thinking of developing an iPhone app or Android App, or any other kind of mobile app, which needs to present users with the ability to search a large chunk of text very rapidly, please contact me, for advice on optimal ways of implementing such a search.

Trivia Crack – One of the most profitable mobile apps

Posted by Eric Worrall on February 5, 2015 in Android App, Android Development, iPhone App, iPhone Development, Mobile App, Mobile Development 0 Comment

Trivia Crack - a simple idea which has taken the mobile app game world by storm. — Trivia Crack – a simple idea which has taken the mobile app game world by storm.

When you think of blockbuster mobile app games, you normally think of huge hollywood budgets, million dollar special effects and 10s of thousands of hours of mobile app development effort.

The reality is, some of the biggest iPhone Apps and Android Apps are nothing of the sort – they are simple ideas which caught on, earning a fortune for their creators.

One of the biggest games to date is Trivia Crack – a mobile app based on the old favourite Trivial Pursuit.

According to Venture Beat

After catching on big time in the U.S. and Canada, Trivia Crack has expanded to countries like U.K. — and this is helping fuel its domination of the mobile app markets.

Trivia Crack is the top downloaded game on mobile in the world, according to developer Etermax and industry-tracking firm App Annie. Since its debut, this app has racked up more than 125 million downloads worldwide. It has also managed to reach the No. 1 spot on the overall app download chart in important countries like the United States and Canada. With mobile gaming revenue reaching $25 billion in 2014, Etermax carved out a piece of that for itself by appealing to casual players with a trivia app that hooks heavily into social media.

Trivia Crack pits players against their friends in a Trivial Pursuit-style quest of knowledge. It already has over 200,000 unique questions, and — thanks to its players — it gets 2,000 new questions every day.

Important Lessons

There are some important lessons we can learn from the success of the Trivia Crack game.

The use of social media – friends challenge each other via social media, which helps to propel the explosive growth of app users
The enlistment of users to supply new questions – these guys don’t even have to think up new questions themselves, they get their users to do it for free.
Simplicity – the game doesn’t pack in every imaginable feature, or heavy servings of Hollywood Glitz, it is just Trivial Pursuit, with a few adaptions to make it more attractive in a mobile app environment.

If you have an idea for developing an iPhone App Game or Android App Game, and you are worried that your idea is too simple to work – please don’t let that stop you. Because when appealing to mobile users who are snatching a few few seconds from their busy schedule, simple is good. And if users like your idea, you could have a runaway success on your hands.

Contact Me to discuss your mobile app development idea now.

Where’s the money in Mobile App Development?

Posted by Eric Worrall on February 4, 2015 in Android App, Android Development, iPhone App, iPhone Development, Mobile App 0 Comment

How to make money from mobile app development

App Developer magazine has printed an excellent article which describes how some people are making vast fortunes from mobile app development.

According to App Developer magazine

Show Me the Money!

The profit model for apps has shifted dramatically in the last couple of years. Distimo’s Unveiling the Secrets behind App Store Category Dynamics report was very illuminating. It revealed that 90 percent of all revenue generated on Google Play and 74 percent of Apple App Store revenue in February 2014 came from games. In the consumer space, games are clearly where it’s at.

For business the rise of enterprise apps is an important trend. An interesting post at Developer Economics last year suggested that the average revenue per developer involved in app development is four times higher for the enterprise than for the consumer segment.

Obviously much depends on your skills, your ideas, and your contacts, but choosing your focus is only the beginning.

Mobile Apps are high risk, high reward. It takes careful planning, dedication and commitment to create a mobile app success. But for the owners of successful mobile apps, the profits can be extraordinary. For example, according to the article in App Developer magazine

… one of the top games right now is Supercell’s Clash of Clans, which makes more than $1 million per day.

A million dollars per day

How do you maximise your chance of your iPhone App development or Android App development being successful? The answer, as always, is do your homework. Research what the owners of successful apps are doing to achieve that success, and copy the elements of their success which are compatible with your iPhone App or Android App idea.

One of the most important decisions when developing a mobile app is the revenue model. According to App Developer magazine

When it comes to business models, for consumer apps there’s no contest. Premium apps with a price tag are fading fast. The freemium model, whereby the app is free at the point of download, but includes in-app purchases and sometimes advertising, is dominant.

The Distimo report found that 85 percent of iPhone apps and 78.6 percent of iPad apps are free with in-app purchases. That figure is even higher for Android. A special report from App Annie last June found that a staggering 98 percent of worldwide revenue on Google Play is generated by freemium apps, and 90 percent of those freemium apps are games.

Consumers are increasingly reluctant to spend money acquiring an app, but they are growing more willing to spend on content within apps, especially after they’ve invested some time.

In my experience, the number of downloads a mobile app achieves strongly influences the position of the mobile app’s listing in Apple App Store or Google Play Store. Free apps get a lot more downloads, which puts paid for apps at a potential disadvantage.

The Freemium mobile app model can overcome this disadvantage – with freemium, you get all the advantages of a free app, but you also create an opportunity to convince users to pay a fee for premium features.

I strongly recommend you read the Full Article, if you are serious about creating a profitable mobile app.

If you have an idea for an iPhone App or Android App, and would like to discuss various revenue models, and how they might be implemented, please Contact Me

Mobile App Development: Native or Web?

Posted by Eric Worrall on January 31, 2015 in Android App, Android Development, iPhone App, iPhone Development, Mobile App, Mobile Development, Web Technology 0 Comment

Web App vs Native Mobile App - a Big Development Decision — Web App vs Native Mobile App – an Important Development Decision

Software Development Times has written an excellent article about one of the important early development decisions which needs to be made when developing a mobile app – should you use native mobile app development tools, or should you present your app functionality using web technology – HTML, CSS and Javascript?

According to SDT:

Native apps maximize performance and user experience

Native development is, on average, the most widely adopted approach. Forrester’s latest Business Technographics Global Developer Survey found that, overall, developers build native apps 38% of the time, hybrid apps 22% of the time, and Web apps 27% of the time. That’s not surprising: Native apps offer a great combination of performance and user experience. And when done right, they deliver a high level of customer satisfaction compared to Web applications, as well as enable superior offline processing and storage capability.

But regardless of these benefits, native apps are a challenge to maintain. Developers we’ve worked with report porting costs of 50% to 70% of the cost of the original app for every new mobile operating system the app needs to run on. Plan to support iOS, Android, BlackBerry and Windows? That’s an increase in development costs of 150% to 210%.

Web apps minimize costs and improve agility

While developers on average spend more time building native apps, at least 74% spend time building with a Web-based approach. But with native’s advantages in performance and user satisfaction, why would anyone want to use Web technologies?

Unless an unlimited development budget is available, taking a native-only approach exceeds the reach of many development teams. A good rule of thumb is to estimate 20% to 25% in additional porting costs when using Web technologies, significantly less than the cost of an all-native approach.

Web Apps vs Native Apps

Web Apps, at least for some types of apps, offer a cost advantage if you plan to target a large number of mobile platforms (iOS, Android, Blackberry, Microsoft, etc.).

HOWEVER, web apps in my experience present a challenge if you want to create an app which appears to be native – you can spend a lot of time and effort making web buttons look exactly like native buttons, only to have all the rules change next time Apple or Android upgrade their operating system.

In addition, there are many types of app functionality which would perform poorly if implemented using web app technology. For example, if your app presents a long list of database entries, particularly if you want the contents of the database list to update automatically as the user types text into a search field, the inferior performance of web app technology very quickly becomes an issue – if your database contains more than a 50 entries, it is very difficult to make a web app provide acceptable search performance, without developing native mobile app components to augment the search – which kindof defeats the purpose of using web app technology.

In general I advise clients NOT to opt for the web app approach, unless the functionality of their mobile app is simple and not computationally demanding. While the lure of being able to port the bulk of your app to different mobile platforms with minimal changes might seem attractive, in my experience the risk of unsatisfactory mobile app performance, and the difficulty of achieving that vital last 1% of polish to make the web app into a compelling user experience, more than outweighs any benefits.

The Facebook Web App Experience

I’m not alone in my assessment of the significant challenges associated with creating high quality web apps. Facebook chose to redevelop their web app into a native iPhone app, because of the stability and performance issues their team encountered during development of their web app.

https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920

Scaling up with HTML5

As mobile usage exploded over the last few years, our priority was to ensure that regardless of device, platform, network, or region, Facebook users had a good experience on their mobile devices. To support thousands of devices and multiple mobile platforms, we leveraged HTML5 to build and distribute Facebook mobile experiences across iOS and other platforms.

By allowing us to write once and ship across multiple platforms, HTML5 has historically allowed us to keep the Facebook mobile experience current and widely available, and has been instrumental in getting us to where we are today. We chose to use HTML5 because not only did it let us leverage much of the same code for iOS, Android, and the mobile web, but it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.

So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.

(Re-)Building for speed

One of the biggest advantages we’ve gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you’ll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.

To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.

…

If you would like advice on whether your proposed iPhone App or Android App is a good fit for being developed as a web app, or whether you should choose the native mobile app development option, please Contact Me

Integrating SharePoint, iPhone Apps and Android Apps

Posted by Eric Worrall on September 24, 2014 in Android App, Android Development, iPhone App, iPhone Development, Microsoft, Mobile App, Mobile Development 0 Comment

Microsoft SharePoint

Microsoft SharePoint is a popular content and data management system, which integrates easily with non-microsoft technology, such as iPhone Apps and Android Apps.

The functionality of SharePoint I have experience integrating is SharePoint Lists.

A SharePoint List is a cross between a web document and a database. It provides means for quickly building and maintaining structured data, and defining relationships between different elements of that data.

For example, you can define a Microsoft SharePoint list which holds details of assets which your company manages, such as factories, shops, or other inventory, then define a second list, which provides a maintenance history for each asset. The second list can be linked to the first list, so for example you can enforce that one of the fields in the second list must be the identity of an asset in the first list.

SharePoint takes care of the complexity of handling collaborative updates to list documents, such as versioning of each change.

There is even an attractive web interface, which is compatible with most mobile devices, and several excellent iPhone Apps and Android Apps, for accessing your SharePoint portal.

So why would you ever need a bespoke iPhone App or Android App, to interact with SharePoint?

The reason clients ask me for help with SharePoint integration is because standard, off the shelf apps do not deliver a specific feature or set of features they require.

For example, what do you do if you want to take SharePoint offline? A client had a requirement that mobile apps be able to be used at sites with poor Internet coverage, so they needed an app which could populate the fields of new SharePoint list instances, and save the new instances in the internal storage of their iPad device, so all the saved changes could be applied to the server once the user had access to the Internet.

Another scenario, a client wanted to extend SharePoint functionality with app device capabilities, to create the ability to upload mobile camera photos to SharePoint list instances, and to upload GPS readings.

Finally, since the apps are interacting with SharePoint as a data store, the Apps are free to implement their own front end – they can guide users through the data acquisition or data delivery process, by imposing a specific workflow on the users – by granting users a limited view of the underlying SharePoint data, and by ensuring all necessary steps of a workflow are executed in the correct order.

A bespoke SharePoint iPhone App or Android App can preserve SharePoint flexibility. It is entirely possible for mobile Apps to apply the bespoke SharePoint functionality extensions on a list field by field basis, to allow the list structure to be changed, to allow new fields to be exposed to users without having to release a new version of the bespoke iPhone or Android SharePoint App.

Bespoke Customisation of the SharePoint experience can help with delivering acceptance and enthusiastic adoption of the underlying SharePoint implementation, by painlessly integrating user requirements which are not best handled by the standard toolset.

Contact me now, if you have or are interested in creating a Microsoft SharePoint based user experience, but have requirements which go beyond what the standard tools can deliver.

Talking to your Android and iPhone Mobile Apps

Posted by Eric Worrall on April 26, 2014 in Android App, Android Development, iPhone App, iPhone Development, Mobile App 0 Comment

Apple iPhone App Developers are all waiting with baited breath for Apple to allow open access to their SIRI engine, Apple’s engine for understanding spoken communication. As of the last time I checked (about 5 minutes ago), Apple does not allow Apps to start SIRI – so users can choose to say fill a text field with SIRI, but the app cannot start SIRI on behalf of the user.

Android has a voice recognition window which an app can open – but it is not really under the control of the app. The Android app can request that the Android phone or tablet present a window which accepts voice, then when the user indicates they have finished speaking, Android passes control back to the app, which can analyse the result of the voice recognition effort.

Neither of these options is “natural” – both the iPhone and Android option are in my opinion clunky, they require the user to take positive action to restore control back to the app.

If your iPhone app or Android app needs hands free voice control, the app needs to be able to initiate voice recognition, detect when someone is speaking, and process the voice to determine what was said, independent of whether the user presses a button.

Thankfully, third party service providers have filled this gap.

My favourite is Dragon Mobile. Dragon Mobile SDK is provided by the same company which publishes Dragon Speech, the legendary desktop PC speech recognition application, Nuance. Nuance has been in the game for over a decade – from somewhat humble beginnings, their product has developed into a sophisticated and reliable speech recognition system, a remarkable achievement in artificial intelligence.

The only downside of Dragon is it relies on an Internet connection. The processing power required to recognise and interpret normal spoken sentences is far greater than an Android App or iPhone app can deploy, so Dragon SDK ships the compressed sound files via the Internet to their servers.

What is the Internet bandwidth is an issue? There are still options. An Android App or iPhone app does not have the processing power to interpret any arbitrary spoken sentence, but it does have the processing power to recognise individual words. So if your iPhone app or Android app only has to recognise a handful of words, such as “yes”, “no”, and “maybe”, then the processing power for this simplified task can be comfortably accommodated without an internet connection to an external server.

If you are interested in Android Apps or iPhone Apps which can recognise speech, or which can read text from images (optical character recognition), please email eworrall1@gmail.com, to discuss your requirements.