This topic is obviously not new. Everyone talks about it. Sooner or later. After making these choices couple of times and talking with customers I noticed common misunderstanding, misuse and mistakes people do(and so did I). There are lots of great articles out there which help out deciding, but still I think it could be brought in a better form. And that's what I'm doing here. I'm delivering mobile technology choices in a form of Binary Decision Tree. I'm starting with the results, further on I'll cover it with the details, and in the end I'll give 4 case studies which demonstrate different choices.
And don't get me wrong. I don't like the idea of silver bullet work flow chart that makes the decision for you(though here's a good one, still I disagree with some points). This decision tree is intended to help you better understand the correlations between your requirements and corresponding technology. You can think of it as unraveling the cables behind that old audio/TV/any system. It's still complicated, but it's much clearer now.
So, how does it work? Basic idea is to define your requirements from the product vision, and then, by prioritizing them, go left or right in a tree. Then you repeat it until you've reached the leafs, i.e. the bottom of a tree. Pretty easy, isn't it?
Now let's delve into details.
The first choice to be made is whether you want a Mobile App or Web App(Site). You probably heard of topics like "HTML5 vs Native." I think it's a bit confusing and too generic comparison, as with HTML5 you can build both web and mobile apps. My point is that you shouldn't choose between Native and Web. Native is a way of implementing Mobile App. Web is a whole family of apps, with its attributes and specialties. Instead, you should choose between Web and App approaches as they deliver more or less equal alternatives, cover different usage scenarios and reflect different marketing channels. And these are basic criteria you want to base upon when choosing mobile strategy.
So, the criteria. I'll start with the easy ones: if you know you're gonna need access to device features(gyroscope, accelerometer, bluetooth, contacts, calendar, push notifications), you care about security or you need non-trivial computation tasks - in these cases you can forget about Web App. You simply don't have required APIs for device features, you don't have infrastructure for security and web has been proven not to be able to deal with heavy-computational tasks.
Please note, I didn't include offline and camera access here on purpose. This is one of most common confusions people make in this field. Web has already grown to an extent where whole websites can go offline(and I'll give you an example later on). And about camera - there is a big progress and workarounds there so before eliminating web as a platform for your app it's better to make deeper investigation. I must say, in my humble opinion, HTML5 s moving(slowly though) towards accessing all these device features, so in future(far future) that will not be a show stopper.
Then, if you don't have a need for any of listed above, you need to define and prioritize the following criteria.
User Experience
Questions: What do you expect from user? How do you want to interact with him? Do you want him just to read information or to input something? How often do you want him to use your app?
Hints: Mobile apps are more adapted for interacting with users and entering information, although skilled web developer can nail it in the web. In contrast, when a user just googles for some information, he doesn't want to download the app, he just needs the piece of advice as quickly as possible. Yes, by the way, one fact you should always keep in mind - mobile users are much less patient than desktop users. As Eric Reiss, usability expert, states, the three-clicks rule is not applicable to the mobile environment. Users will leave your system the moment they feel it doesn't bring much use to them, i.e. possibly after the first click.
Content
Q: What is it that you're showing to your user? Is it a daily newspaper article, or a 3D model of his new house? Or maybe a medical record input form?
H: Content is tightly integrated with user experience, he actually defines it. I highlighted it as a separate criterion to help you better understand your UX strategy. Here's a good popular tip from Prasant Varghese:
Q: How do you want to deploy your app? How do you want to deliver updates? How do you want users to reach your app? What is your maximal time-to-market?
H: Apple has started a very good culture with its AppStore. Apps there are easy to find, to choose between competitors thanks to rating & comments and have good compatibility model. Those are huge pros for mobile apps. The con would be bigger time-to-market because of Apple's and Microsoft's review process(if you're aiming Android, BB or enterprise that's not a problem). Also, there may be scenario where you want to employ your own distribution model, or you already have good SEO rating for your website and just want it to go mobile. Choice is yours.
Monetization Model
Q: How do you return your investment? Is it a part of your marketing
campaign? Or are you going to monetize your application? Do you want to use built-in methods of payment?
H: Some build apps to sell them. Some to market their company. Some to improve their employees productivity. Anyway, if you want to deal with money, it's better to go the App way, as there are built-in user-friendly ways to handle money transfer from inside the app, or when buying the app itself. Again, if you have your own well-made monetization model you can go your way
Portability
Q: Who is your target audience? What devices are they using? Phones? Tablets? Phablets? Which OS? How much devices are your going to support? Is functionality the same for all devices?
H: Both App and Web can give you great portability, just for different cost. Going Web usually means (if made correctly) that everyone can use it. When going the App way, you'll have to pay more(Native) or less(Hybrid) for every new platform. Learn your audience and what devices they are using. If you have really diverse audience(e.g. you're a food retailer) and your customers have all range of phones from old Nokias to brand new Nexus' it makes sense to have a website which will cover them all. On the contrary, if you have more specific customers, like lawyers, who usually use iPhones, you can save some budget by cutting support of other screen sizes or platforms. One more advice - don't rely on statistics of browsing your (desktop) site from different operating systems too much . It is typical that user who has visited your site and didn't like it, won't visit it anymore. Better learn who do you want to use your system.
Budget
Q: How far can you go to reach the best quality? Where is "good enough" for you? What is the long-term planning?
H: For most people this is final word. Keep in mind cost of development, testing, maintenance, deployment etc. It's not a secret that App way will be more costly. You should also consider in what tools and technologies you want to investigate, i.e. what types of applications you are going to build in future.
Also, consider choosing both ways - Web and Apps for several platforms. Here's a quote from Jason King which describes budgeting very well (source)
Also, note that I didn't give such popular criterion as availability of developers for right technology. I'm sorry, that's just too obvious for me. If you don't have people to use certain technology - then you can't afford it. Or, if you really need some technology - you'll find the people somewhere.
Just to use the right moment, here's another good source of topic that we were talking about.
So, we've made the most important part - we've set a line between an app and a site. Now we're going to see the difference in technologies for developing each. I like the polish notation, so will go to the apps first.
As for me, the choice between Native and Hybrid is the matter of investment. If you buy something expensive, you get good quality result, no head ache and smooth process. If you buy something cheap, and save money, it has to show up at some point. You get either worse quality, a lot of problems down the road or the high risk of failure. It's like buying tickets from resellers at the concert - they're twice cheaper, but you have no guarantee you'll get inside. So think twice, whether you want such an approach for your business.
It may be a surprise for someone, but people actually created a lot of ways just not to deal with Objective C:) No, just kidding. The idea of cross-platform development isn't new - we've had it with Java for Linux, Windows and the rest of the company, we had it with HTML5 for different browsers, there's similar problems in gaming world(PlayStation, XBox etc). It's absolutely normal to want your code to work across all the platforms. But the world is not fair, and this comes with the price.
Back around 2005, when all enterprises were still on BlackBerry, we were in a middle of a huge project, developing product for lawyers' time-tracking. The system worked well without mobile part, but the time has come and mobilization took it's part.
Somewhere around 2008-2009 we had a task to implement a small app to help couriers do their job more effectively. Each one of them would receive an Android tablet, and every morning all of them would had a list of new orders, which was shared between them. Everyone could pick orders that was closer to him and everybody else would see it. This process was managed by coordinator and his responsibility was to deliver all orders. Also, when courier delivered the order he asked to recepient to sign on the tablet(yes, physically draw the signature over a tablet with a stylus), which would generate a PDF document, that was saved on server then. When choosing, our main priority, brought from customer, was budget. So we looked for ways to do it cheap. The functionality wasn't that difficult, most of development time was estimated for UI controls, as we needed a long grid with checkboxes, buttons and other custom controls. As Android was still raw back then, and we had good web specialists, we decided to try a Hybrid approach, by reusing Ext.js controls and therefore saving a lot of time. But take into account - there was no PhoneGap at that moment. And this solution was even more riskier then it is now. And we had to implement our own communication layer between JavaScript and Java. Surprisingly from retrospective, but it worked, worked well and was still much cheaper then going Native.
But then we got to signing functionality. It was way too slow through WebView layer. But impossible is nothing! We implemented it in Java, the Native way, and injected into the hybrid part of application. And everyone was happy ever after :)
I love this example as it shows how combining different technologial approaches may benefit the final result. For more details you can follow this link.
Recently our marketing department together with UX department had a great challenge to showcase our expertise in Web Design and Web Development by redesigning our own web site. The main priority of course was the quality of the result. We knew that we will update the content frequently, that we want to reach as wide audience as possible, that all we want is to present information, not to interact with users. So it was clear that we don't need an app, and it was clear that we don't want two separate websites. We wanted responsive. And, in my humble opinion, as a person who didn't participate in this project, the result is awesome. Oh, yes, it's not just my opinion, we won quite nice awards for this work. Here's a nice interactive case study explaining how me made it.
And don't get me wrong. I don't like the idea of silver bullet work flow chart that makes the decision for you(though here's a good one, still I disagree with some points). This decision tree is intended to help you better understand the correlations between your requirements and corresponding technology. You can think of it as unraveling the cables behind that old audio/TV/any system. It's still complicated, but it's much clearer now.
So, how does it work? Basic idea is to define your requirements from the product vision, and then, by prioritizing them, go left or right in a tree. Then you repeat it until you've reached the leafs, i.e. the bottom of a tree. Pretty easy, isn't it?
Now let's delve into details.
Choosing between App and Web Site
I intentionally rooted my decision tree with a Vision, as this is a thing, without which you cannot start choosing the technology. You have to know what you're aiming for before you start shooting. Then, you need to turn the vision into some more specific requirements. I'll help determining the criteria, but there is still work to be done with setting the requirements and understanding them.The first choice to be made is whether you want a Mobile App or Web App(Site). You probably heard of topics like "HTML5 vs Native." I think it's a bit confusing and too generic comparison, as with HTML5 you can build both web and mobile apps. My point is that you shouldn't choose between Native and Web. Native is a way of implementing Mobile App. Web is a whole family of apps, with its attributes and specialties. Instead, you should choose between Web and App approaches as they deliver more or less equal alternatives, cover different usage scenarios and reflect different marketing channels. And these are basic criteria you want to base upon when choosing mobile strategy.
So, the criteria. I'll start with the easy ones: if you know you're gonna need access to device features(gyroscope, accelerometer, bluetooth, contacts, calendar, push notifications), you care about security or you need non-trivial computation tasks - in these cases you can forget about Web App. You simply don't have required APIs for device features, you don't have infrastructure for security and web has been proven not to be able to deal with heavy-computational tasks.Please note, I didn't include offline and camera access here on purpose. This is one of most common confusions people make in this field. Web has already grown to an extent where whole websites can go offline(and I'll give you an example later on). And about camera - there is a big progress and workarounds there so before eliminating web as a platform for your app it's better to make deeper investigation. I must say, in my humble opinion, HTML5 s moving(slowly though) towards accessing all these device features, so in future(far future) that will not be a show stopper.
Then, if you don't have a need for any of listed above, you need to define and prioritize the following criteria.
User Experience
Questions: What do you expect from user? How do you want to interact with him? Do you want him just to read information or to input something? How often do you want him to use your app?
Hints: Mobile apps are more adapted for interacting with users and entering information, although skilled web developer can nail it in the web. In contrast, when a user just googles for some information, he doesn't want to download the app, he just needs the piece of advice as quickly as possible. Yes, by the way, one fact you should always keep in mind - mobile users are much less patient than desktop users. As Eric Reiss, usability expert, states, the three-clicks rule is not applicable to the mobile environment. Users will leave your system the moment they feel it doesn't bring much use to them, i.e. possibly after the first click.
Content
Q: What is it that you're showing to your user? Is it a daily newspaper article, or a 3D model of his new house? Or maybe a medical record input form?
H: Content is tightly integrated with user experience, he actually defines it. I highlighted it as a separate criterion to help you better understand your UX strategy. Here's a good popular tip from Prasant Varghese:
If your goal is just to display and show content, I suggest a responsive or mobilized website. If your goal is to show productivity tools, build an appDistribution Model
Q: How do you want to deploy your app? How do you want to deliver updates? How do you want users to reach your app? What is your maximal time-to-market?
H: Apple has started a very good culture with its AppStore. Apps there are easy to find, to choose between competitors thanks to rating & comments and have good compatibility model. Those are huge pros for mobile apps. The con would be bigger time-to-market because of Apple's and Microsoft's review process(if you're aiming Android, BB or enterprise that's not a problem). Also, there may be scenario where you want to employ your own distribution model, or you already have good SEO rating for your website and just want it to go mobile. Choice is yours.
Monetization Model
Q: How do you return your investment? Is it a part of your marketing
H: Some build apps to sell them. Some to market their company. Some to improve their employees productivity. Anyway, if you want to deal with money, it's better to go the App way, as there are built-in user-friendly ways to handle money transfer from inside the app, or when buying the app itself. Again, if you have your own well-made monetization model you can go your way
Portability
Q: Who is your target audience? What devices are they using? Phones? Tablets? Phablets? Which OS? How much devices are your going to support? Is functionality the same for all devices?
H: Both App and Web can give you great portability, just for different cost. Going Web usually means (if made correctly) that everyone can use it. When going the App way, you'll have to pay more(Native) or less(Hybrid) for every new platform. Learn your audience and what devices they are using. If you have really diverse audience(e.g. you're a food retailer) and your customers have all range of phones from old Nokias to brand new Nexus' it makes sense to have a website which will cover them all. On the contrary, if you have more specific customers, like lawyers, who usually use iPhones, you can save some budget by cutting support of other screen sizes or platforms. One more advice - don't rely on statistics of browsing your (desktop) site from different operating systems too much . It is typical that user who has visited your site and didn't like it, won't visit it anymore. Better learn who do you want to use your system.
Budget
Q: How far can you go to reach the best quality? Where is "good enough" for you? What is the long-term planning?
H: For most people this is final word. Keep in mind cost of development, testing, maintenance, deployment etc. It's not a secret that App way will be more costly. You should also consider in what tools and technologies you want to investigate, i.e. what types of applications you are going to build in future.
Also, consider choosing both ways - Web and Apps for several platforms. Here's a quote from Jason King which describes budgeting very well (source)
Desktop, mobile web, and apps are all different marketing channels. You have to decide where to focus your development budget...If you have the budget, do it all.A very popular scenario is to develop an app for most important audience and make a web site with limited functionality to cover all the rest. When budget is limited and functionality allows, the killer combination is HTML5 code base with tuning for accessing device features for Hybrid tools(PhoneGap, Titanium) and tuning for workarounds without these features for web site. But don't ask me about maintaining this code base and the number of branches there.
Also, note that I didn't give such popular criterion as availability of developers for right technology. I'm sorry, that's just too obvious for me. If you don't have people to use certain technology - then you can't afford it. Or, if you really need some technology - you'll find the people somewhere.
Just to use the right moment, here's another good source of topic that we were talking about.
So, we've made the most important part - we've set a line between an app and a site. Now we're going to see the difference in technologies for developing each. I like the polish notation, so will go to the apps first.
Choosing technology for the App
First of all, let me give my definitions of Native and Hybrid. I call Native the official way to build mobile applications, as declared by each platform's vendor, i.e. Java + Android SDK for Android, Objective C + iOS SDK for iOS etc. I call Hybrid all the tools to develop mobile apps in any other way. Still on Internet more accepted term for Hybrid is something between Web and Mobile App.
Now, to set the right angle for this conversation I'll start with the following fact. When each mobile platform was out, the only way to develop applications for it were the recommended vendors tools, i.e. native APIs and correspondent programming languages. Later, as the tools were a bit difficult to migrate from mainstream web development to uprising mobile development, people started inventing hacks, which could simplify this procedure. Remember ASP.NET? When Microsoft tried to help shifting desktop developers to web development with hacks like viewstate? Well, this is something similar.
Another problem Hybrid tools solve is cross-platform development. So that you can build one application which would work everywhere. Without worrying how it works on all these platforms. But these hacking tools don't save people from learning all the aspects of mobile development. At least they shouldn't. And that's a very common mistake - to think that knowledge of language will save from learning the infrastructure. Sooner or later you'll have to deal with the details. And same way we learned about hurdles with viewstate we'll have to learn about hurdles of Hybrid tools. And that's the way it is.
As for me, the choice between Native and Hybrid is the matter of investment. If you buy something expensive, you get good quality result, no head ache and smooth process. If you buy something cheap, and save money, it has to show up at some point. You get either worse quality, a lot of problems down the road or the high risk of failure. It's like buying tickets from resellers at the concert - they're twice cheaper, but you have no guarantee you'll get inside. So think twice, whether you want such an approach for your business.
Still there are situations where Hybrid can be the right choice without a big loss. I've set 5 criteria for choosing between Native and Hybrid approaches(which intersect at some points with your previous choices)
Future
The big drawback of Hybrid approach is that at some point you just might get stuck and not be able to implement something as when using Native approach. And although in most Hybrid tools there's a space for injecting native parts, it might get really tricky. So my recommendation is not to choose Hybrid if you see great extensions to functionality of your app in future.
Risks
Define the level of risk you can take. The risk of failure, the risk of higher costs of maintenance, of getting stuck and switching to Native, of immature technology and community, all the other risks. If you have a mission-critical project - go Native.
Portability
Again. If you target more then 2 platforms it makes sense to go Hybrid. But don't underestimate the cost of adapting the codebase to each platform. Write-once-run-everywhere is a myth. It's rather write-once-fix-everywhere. There are lots of design differences between Android, iOS and other platforms, which you'll have to take into account. Also building and deploying processes are specific to each platform.
Performance
Obviously, and as it was mentioned before, Hybrid apps are usually slower(although Cross-compiled seem to make a difference). The very well known fact is that Facebook dropped their Hybrid approach because it simply didn't meet the UX expectations from users and they didn't use it. When Facebook switched to Native it was a bliss for users and a shame for HTML5-believers. Though Sencha quickly responded to this. A lot of people use it as an argument for Hybrid apps. But I'll tell you one thing, this demo was built not as a Hybrid app, but as a Web Site. And it's a very well-known fact that hybrid apps are much trickier than websites, because WebViews are more limited then browsers(e.g. no Nitro engine on iOS). So if you got on this side of the tree because of performance or UX then it's very simple - go Native.
Budget
Of course. I've already said too much about it. No more comments.
Choosing between Hybrid technologies
So, there are basically three ways to write Hybrid apps. Two of them are very similar, which is why I've distinguished only 2 in a decision tree. I'm not going into too much details here, but I'll give basic idea about how they work, what are the differences and what are the choosing criteria.
WebView-based, aka PhoneGap
The idea is that you put a single control called WebView on native part(instead of building page control tree as it's done in Native way), and write all your functionality inside it. The WebView is kind of a web browser inside native app. This way, you build mobile application as static web site, but it will be a bit slower. The communication layer between native and WebView environments lets you use all functionality from native part by using special javascript APIs. In return you get a lot of head ache and mystery. For more details see my previous blog post about PhoneGap.
Custom container-based, aka Titanium
The idea is that you have a container on native part, inside which you execute your custom code (in Titanium it's javascript), and you have a communication layer between native and containerized part, so you can also access all native features. This container could be V8, Rhino, a mentioned WebView or many others. All container has to do is execute custom code and provide communication between 2 worlds. With this approach you generally do not build a mobile app as a static web site, you only reuse javascript code base. In further discussion I won't distinguish these 2 approaches as technically they are subset of one another and practically the pros and cons are almost the same, although their philosophies differ. Here's a good article from Appcelerator's employee comparing PhoneGap and Titanium.
Cross-compiled, aka Xamarin
The idea is that you write code in one language that will be later cross-compiled to other platforms' native code. This way you get both cross-platform code and native experience. Although you can reuse only core logic, you'll have to write UI for each platform separately. A fair limitation, imho. A bit confusing, and with a lot of questions(memory management, language specific structures etc), but a very promising approach. I personally like it because unlike containerized approaches it doesn't abstract you away from each platform's architecture. You still have to be aware of how each platform works. You just get your favorite language codebase across the project. A detailed article on Xamarin is soon to be released on elekslabs.com.
Before comparing these I'll remind you - you're on this part of the tree because you are have the low budget, you accept risks, you don't expect a great performance or you look for great portability.
To be honest, Cross-compiled looks like something between the Containerized and Native ways. A bit less performant then Native, a bit less portable then Hybrid, a bit more expensive then Containerized. But I decided to leave it on this side of the tree as it still provides great risks of unknown and the most representing platform is still on its maturation journey. If this wouldn't be a binary tree maybe I'd put it in the middle. Now, I see 4 criteria for choosing Cross-compiled vs Containerized.
Native Experience
How close to Native do you want to get? Now that you're in this risky part of the tree, you still can get good performance if you go Cross-Compiled
Platform Maturity
With all respect to Xamarin, PhoneGap is a bit older, and has at least taken its fair place in technology comparison. Not every average developer is aware of Xamarin and how it works, but most of them have heard about PhoneGap(good or bad stuff)
Preferred Tools
Hybrid approach is based on reusing existing skills. So if you are ready for taking Hybrid approach you can choose language and tools you like more. Me, for example, I feel more productive when armed with C#/R#/VS then with JS/N++ although I love both.
Portability
Third time in a row. I'll say it quickly. As Xamarin apps can't reuse UI part, it's a bit harder to migrate code base across platforms with Cross-Compiled.
Few, that's it, we're done with all the apps stuff. Just to take a fresh breath I'll share the beauty which inspired me while writing this article.
Choosing between Web technologies
There are 2 popular ways of building mobile-friendly web site: making a separate web site for small-screened devices or making a web site which would fit to all kinds of screens, i.e. a responsive web site. Let's see how they can be compared and when to choose which one.
Screen Size Range
It's a similar question to portability. How diverse is your user base? Do you need to support every couple of inches or is a common 3-4 inch enough for you? Do you want to support Tablets?
With Responsive approach you'll have a good appearance on all kinds of devices. If you want to achieve it with separate site, you'll have to build couple of them, for different screen sizes each. But usually a separate site is done when only mobile phones are in focus and average appearance on tablets is satisfactory.
Support
If you have 2 web sites, you must understand how much more difficult it is to support them - from fixing bugs to changing content. In terms of support Responsive wins the battle
SEO
As with Responsive you've got only one site, you have the ranking summed up from mobile and desktop devices. That's a big advantage for discoverability.
Full Redesign
All these benefits come with a prize. To build a Responsive site you usually need a full redesign of you existing site, which would of course cost more then just implementing mobile-friendly version. In case you're building a new site , it's not a problem. But if you're in a middle or running business and have just recently updated your web-site's design you have a tough decision to make.
Budget
There are lots of discussions on Internet about which approach is cheaper. The general agreement is that Responsive is cheaper in a long-term, but more expensive in the beginning, especially if you're dropping your previous design to make a brand-new mobile&tablet-friendly web site.
Ok, now we're done with decision tree, and to wrap it up I'll give you couple of case studies which prove all the text above.
Case Studies
All case studies here are examples of the projects we did here on ELEKS. The fact is that the most popular decision among our customers is opting for the App. But we also had less obvious technology choices, and I'll share them with you to demonstrate how diverse requirements can be and what technologies they fit the best.
An all-platforms App for Time Tracking
The purpose of product was to simplify reporting process for lawyers and help them create and manage records. And mobile phones was a great enhancement to general idea. Records could've been created based on calls received, emails read and meetings attended. And that's exactly what customer asked us to do. As we needed to support only BlackBerry, and the budget was fair, no one even thought about other ways then building apps the way RIM recommends to. And that even wouldn't be possible as we needed access to a lot of device features. Decision was made, application was built, everybody was happy.
And then iPhone came out in 2007. We couldn't reach same functionality because of platform limitations, but still it was a native app. At some point of communication with customer there was an idea to switch to Hybrid, but the decision from customer was very clear - the product is meant to improve lawyers' productivity, so it needs to be on top of user experience practices. And couple of years later we started developing Android version. So we have an app running on 3 platforms, and it's still Native.
A Mobile Web App for Healthcare
At 2009, we had a lead from one US customer, asking us if we could build mobile medicare software product. The functionality would be not far from common - inputting information about patients, receiving some information from server etc. Although there were tricky parts, like supporting offlline mode and syncing with server when going online. Customer wanted the app for iOS, Android and possibly other platforms. We evaluated the functionality, and identified potential simplification with HTML5 which wasn't so much HTML5 back then. Still even then, there was a documentation on Offline Manifest and local storage with doubtful support among browsers. To make it clear, the idea of cache manifest is to include a file in your web site, which will tell the browser which files it needs to cache locally, so that if user visits web site again without access to internet, the browser opens the cached version. So we made a prototype and it worked! (not without surprises of course). At least on out target browsers, mobile ones, it did. Customer was more then happy for a double cost reduction and a little change in user experience(opening browser bookmark instead of opening the app) was more then ok price for such a big save. So we were glad to win the lead and the customer was glad to save money. As far as we know users are very satisfied with the system too. What a love story! For more details you can read this document.
A Hybrid App with Native injections for Logistics
But then we got to signing functionality. It was way too slow through WebView layer. But impossible is nothing! We implemented it in Java, the Native way, and injected into the hybrid part of application. And everyone was happy ever after :)
I love this example as it shows how combining different technologial approaches may benefit the final result. For more details you can follow this link.
An ELEKS' Responsive Web Site
That's all, folks
I was very happy to share this knowledge with you, and I'd be even more happy with comments/critics/discussions on this topic. Feel more then welcome to contact me at markiyan.matsekh@eleks.com and stay tuned for more interesting articles on elekslabs.com. I'm planning to release research articles on Enterprise Mobility, Xamarin, and Wearable Technologies in not to distant future.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.