Android apps … for MV?

I have a feeling I know what the answer here is but… I’ve been working on Android apps recently and I was wondering what people think about an Android-based front-end to their MV app. I’ll prep you now, there’s a bit of commentary here. I’m just slamming out the text as I think about it on a slow Friday.

A lot of people aren’t sold on the concept of an “app” yet, for Android or any other mobile platform. If they believe in mobile computing at all, a typical response to “why not apps” is that they can just use a browser page to display info and interact with the user. Sure, a web page can satisfy some requirements but not all. As always, we need to use the right tools for specific jobs. As a simple example, devices receive notifications as well as allowing the user to request information. The device will pro-actively notify the user when something of interest has changed. Unlike web pages, apps also integrate with other phone components like Contacts, the camera, GPS, voice IO, and other apps that make their services available.

Note that cameras are now being used for document scanning as well as taking cute pictures. They can process barcodes and QR codes, meaning they can serve as portable scanners for document and package processing.

For Pick people who say they still don’t like it or don’t get it, remember, this isn’t for “you” as an MV developer, it’s for end-users, to help them do what they do, and that includes seeing more value in the application that you provide.

End-users can get a great deal of use from mobile connectivity to your software. An app can be created which displays and organizes sales data, accounting anomalies, manufacturing workflow status, patient status, customer history, etc. SMS can be used for some of this, sent from the DBMS to specific phones, but it might not be elegant to mix normal SMS/texting messages with inbound business notifications, and of course SMS doesn’t expose a context-relevant GUI. SMS is also insecure where apps can easily be made secure. You can also do things like syncing phone contacts with your MV customer file, allowing clerks to get pricing and availability by scanning the UPC on a product, even maintaining a local subset of your database on the device for “offline” access.

Consider that sales are lost when customers simply forget to come in and make a scheduled purchase. When provided to customers of your MV app users, a device app can notify people when goods are ready, or it can add schedule data to their calendar. For example, a patient with the doctor’s app can automatically have their calendar loaded with prescription renewal info and appointment data, and a service centers (oil, muffler, transmission, warranty, etc) can have notices sent based on time or anticipated mileage, hours, or product usage.

With mobile devices now outnumbering the human world population it’s a bit ludicrous to assert that there are no mobile applications of value to this marketplace, which seems to be the general attitude. Whether you use Android, iPhone, Blackberry, Windows Mobile, or another platforms, the chances are now quite high that you use a smart device, and that you’re downloading apps, even paying for some. Chances are probably much higher, say 90+%, that your end-users and their customers (and their customers family) are all using such apps. The smartphone is just another user interface now, but one that virtually everyone has on their person, all the time, compared to dumb terminal or even a PC with telnet.

I’ll be happy to help people get started with Android development for use with their MV apps. And if you’re interested in other devices, we can talk about those as well.

I think I know what the problem is with mobile, web sites, web services, plugins, add-ons, telephony, and all of the other stuff I talk about here in my blog and in forums. It’s that many of the people reading this think it’s OK for me, but not for them simply because they don’t know how to do it. “I won’t provide web services to my clients because I can’t really say what a web service is and I don’t want to have to support it.” I’ve heard something similar to that from a few people. “I don’t know .NET or Java or PHP … so I’m not going to provide my clients with a GUI.” That’s really the crux of all of this. I completely understand that a value-add developer wants to understand what he’s selling to clients, but at some tier people need to let go of that. You don’t know the C++ or assembler code that goes into your DBMS, but you sell it anyway. You don’t know the messages passed in Telnet protocol initiation, nor the escape sequences for various terminal types, but you use that anyway. You use products like AccuTerm and wIntegrate because you trust the providers to make changes when required – you’re not concerned with how they work, only that they do. You may not know the details of a combustion engine and you may have never changed your spark plugs, but you buy a vehicle that works and bring it to someone else to maintain when it doesn’t. And while you use and deploy open source code every single day, you never look at that code and don’t really feel a need. The same goes for other bits of software which are of use to your clients – like GUI and web services and mobile apps.

Even if you’re not thinking about Android development right now, or at all, what are your thoughts about mobile devices as clients to a business application?

If you’re adverse to mobile integration with your apps, or just pessimistic about the value, I’m wondering if you could explain your position in email or as a comment here, given the plethora of apps available and such widespread usage. Maybe if we understand all sides better we can work out better solutions.

As usual, I find it fascinating that somehow the Pick market feels that something that the rest of the world does somehow doesn’t apply to people who use our software. End-users who use Pick aren’t Pick people. They’re as mainstream as everyone else, a random sampling of the population not bent toward any “traditional” mindset or with wants or needs somehow different from their neighbors. Whether Pick people see value in mobile devices or not, everyone else does. Those are the people who pay the bills. Those are the ones for whom we need to create mobile interfaces, and websites, and web services, and other mechanisms to make better use of the fine business rules which we provide. Because despite the great business rules which we hold so dear, if they’re just exposed through a character/telnet interface, we’re going to lose those end-users. That’s simply a fact that is re-proven every day.