engineering.goinnovo.comInnovo Engineering

Wednesday, February 20, 2013 Native Apps vs. Web Apps: There is a difference Web Apps vs. Native Apps, is a hot topic these days that is getting a lot of attention from developers to marketing campaigns. Everyone seems to be waiting for one side to win and the other be declared the loser. In building our mobile apps at Innovo we had to make a decision to go with Native Apps, Web Apps, or a Hybrid strategy. As a engineering team there are obvious advantages of building pure web apps, especially for a development shop of our size. Being able to build a application once and have it run on any platform sounds like a amazing idea. Here at Innovo, we are not about looking for the 'easiest' way. We are focused on building innovative applications that make a difference in how our customers do business. From a non-technical standpoint, the advantages of a native app to your basic static web site is huge. Native apps have the ability to be a powerful marketing tool. Having an app can give companies an advantage over their competitors and projects their company and brand as being at the forefront of technology. Companies now have the ability to get their brand and company name into various App Stores. Stores which consumers already use everyday for their personal lives for social media, gaming and general productivity. Companies can take advantage of this marketplace and make it simple to get their app onto users devices and create a permeant pipeline to do more business and in new ways. Think about the the ability to instantly communicate sales, events or specials through push notifications to your customer base. Or engage in a conversation with a sales rep via realtime messaging. On the technology side, it is all about usability and user experience. If your people can’t efficiently complete tasks through an application they simply won’t try it a second time. A native app produces the best user experience — fast and fluid, gives you the best access to device features, and can be discovered in the app stores. For our team, Native Apps are the only way to achieve the level of performance, reliability and innovation that our products require. Not sold? Let's take a look at Facebook. Mark Zuckerberg appeared at TechCrunch Disrupt SF 2012 and acknowledged what he believes is the biggest strategic mistake that they have made in the last few years. "The biggest mistake we made as a company was betting too much on HTML5 rather than native" Zuckerberg went on to explain Facebook's direction moving forward... "On iOS and Android, you can do so much better by doing native work, and we need to just do that" Facebook has since shifted to native apps on both Android and iOS. As for the previous web based HTML5 version, they are keeping it in their back pocket for future use but focusing purely on native apps now. These comments from a company at the forefront of mobile technology sent bloggers into a tizzy and got developers around the world talking. Some took what he was saying as bashing HTML5. In the end he is just speaking from experience and is dead on. Here at Innovo we can speak from experience. We recently rolled out a HTML5 web application that is a customer portal for basic mobile device management. It takes advantage of HTML5 features like offline storage, CORS, and responsive design. It is a single web application that can adapt its layout and design based on the device (phone, tablet, desktop) that is accessing it. It is a work in progress. It has allowed us to dabble with HTML5 and really get a understanding of its strengths and the direction it is going. Most eCommerce or mobile web apps are still stuck in the old days. Using technologies like fat-XML and server side rendering. They have yet to realize the wealth of features in HTML5 and how it could elevate their solutions. Regardless, HTML5 has a ways to go before it can compete with native apps. Looking at what we had to build for the portal and thinking about how we might have done that for one of our native apps, it simply is not possible. Maybe that will change in HTML6 or HTML7. We are following a similar path to Facebook. Focusing purely on native apps on iOS and Android. We are going to continue to experiment with HTML5 and web technologies as well as other emerging mobile platforms. Not matter what camp you are in, you need to get your hands dirty with the technology to actually join the conversation. Knocking one side or the other without having any working knowledge of the subject is just plain lame. That is what great technology companies do. Focus your efforts on creating innovation solutions with the best technology that currently exists while always keeping a open mind towards the future and emerging technologies. That is what keeps you relavent and allows you to adapt to the every changing technology landscape. Native apps are clearly the best option for our shop right now. Will that change in the future? Time will only tell... Posted by Unknown at 8:52 AM 3 comments: Email This BlogThis! Share to Twitter Share to Facebook Share to Pinterest Wednesday, November 28, 2012 OAuth 2.0 - What Now? If you have been following the OAuth 2.0 spec (not many have...) you would know that the leaders of the spec have been dropping out left and right. Eran Hammer who was part of the OAuth 1.0 spec and had been working on the new 2.0 spec recently stepped away in June. See his reasons here So where does the specification go from here? That is a hard question to answer. The biggest issue is that the specification is very 'open ended' and that leads to confusion and a lack of interoperability. Case in point, have you checked out the OAuth implementations from Facebook, Twitter, Google, 'Insert API Provider Here'? They are all slightly different. As a developer who has used these various API's it is a pain to learn the nuances of each version of OAuth that providers are using. Each has a different flow (2 legged versus 3 legged), some support Web Server authentication flows, others do away with client-credentials completely. Case in point. Have you checked out Apigee ? It is an awesome site for all things API related. Best practices, developer tools, services and the ability to create your own API Console. When you are building your console (which is awesome - I have built about 3 different web versions myself) there are 2 OAuth 1.0 options and 3 OAuth 2.0 options as well as a fail safe 'custom' security option probably there for 'other' OAuth implementations. Why does it need to be so complicated? So is the nature of the OAuth 2.0 specification, too many flows and extensions have muddied the waters. Here at Innovo we just wrapped up our first version of our API and yes... we implemented OAuth 2.0. It was a difficult task. We spent time reading the current form of the draft and then spent time looking at some of the public API providers of the world to try and find any standards or best practices. In the end I am not sure we ended up with the 'perfect' solution but we stuck to the KISS principle. In my mind Facebook's API and documentation is a good place to start for developers. It is a older version of the 2.0 specification but it works. If you are already using the OAuth 1.0 specification you may not want to upgrade. If you are starting fresh like we were, OAuth 2.0 makes sense. Even with the concerns of a fairly unstable specification, the 2.0 spec can be used as more of a blueprint to produce a secure implementation. Can it really be called 'OAuth 2.0'? Probably not. Will it be interoperable with other platform API's? No. In the end I don't know what OAuth 2.0 really is and according to Eran Hammer... it is dead Posted by Unknown at 1:00 PM 2 comments: Email This BlogThis! Share to Twitter Share to Facebook Share to Pinterest Tuesday, November 20, 2012 And so it begins... Innovo engineers focus on innovation. Working on amazing products and technologies to bring mobile solutions into the Enterprise space...