Earlier today a reader asked me about the possibility of converting his mobile-friendly site into a "real" application via PhoneGap. I told him that this could be very easy. You can take your HTML, upload it to the PhoneGap Builder service, and see what you get. This works with simple HTML sites, but is not going to work well with dynamic sites built with server-side languages. In this blog post, I'll explain why it won't work, and also walk you through an example of converting a (simple) dynamic web site into a PhoneGap application.
Before I begin - two quick notes. I'll be using jQuery Mobile for the UI and ColdFusion for the back-end. This is completely inconsequential to the task at hand. Ok, ready?
First, let's discuss why a dynamic web site can't be simply converted as is into a PhoneGap application. Most of my readers are web developers so you should know this, but when it comes to dynamic server-side languages like ColdFusion, PHP, Ruby, etc, the HTML your browser gets is created dynamically.
Take for example this simple ColdFusion site. When you request this URL with your browser, my web server hands off the request to ColdFusion. ColdFusion does its magic (hits the database) and outputs raw HTML. That HTML is returned to the browser and rendered as is. The same would apply for PHP, Ruby, etc. When you click on the detail page, we hit one template that is passed a URL parameter that instructs the code to load a particular record and display it.
Now - consider PhoneGap. PhoneGap takes your HTML files and packages them up into a native application for your mobile platform. But it is not a web server. You can't bundle in ColdFusion or PHP and have it execute server-side code like in the example above.
Does this mean you're completely out of luck? Not at all. Let's look at how we can convert our code into a PhoneGap application.
First, let's look at the initial application. As I said above, the choice of the server-side language isn't relevant to the discussion. Therefore, I won't go into detail about what the ColdFusion code is doing. Those of you who don't know ColdFusion should be able to mentally map it to the language of your choice. First - the index page.
<cfset artService = new art()> <cfset art = artService.getArtList()> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Art Lister</title> <link rel="stylesheet" href="css/jquery.mobile-1.1.0.min.css" /> <script src="js/jquery-1.7.2.min.js"></script> <script src="js/jquery.mobile-1.1.0.min.js"></script> </head> <body> <div data-role="page"> <div data-role="header"> <h1>Art</h1> </div> <div data-role="content"> <ul data-role="listview" data-inset="true"> <cfoutput query="art"> <li><a href="detail.cfm?id=#artid#">#artname#</a></li> </cfoutput> </ul> </div> <div data-role="footer"> <h4>Raymond Camden</h4> </div> </div> </body> </html>
Then the detail page:
<cfparam name="url.id" default=""> <cfset artService = new art()> <cfset art = artService.getArt(url.id)> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <cfoutput><title>Art: #art.name#</title></cfoutput> <link rel="stylesheet" href="css/jquery.mobile-1.1.0.min.css" /> <script src="js/jquery-1.7.2.min.js"></script> <script src="js/jquery.mobile-1.1.0.min.js"></script> </head> <body> <div data-role="page"> <div data-role="header"> <cfoutput><h1>Art: #art.name#</h1></cfoutput> </div> <div data-role="content"> <cfoutput> <p> #art.description# </p> <p> Price: #dollarFormat(art.price)#<br/> Sold: <cfif art.sold>Yes<cfelse>No</cfif> </p> <p> <img src="/cfdocs/images/artgallery/#art.image#"> </p> </cfoutput> </div> <div data-role="footer"> <h4>Raymond Camden</h4> </div> </div> </body> </html>
And finally - here is the component that drives the data. Basically it just wraps up the logic to get our list and detail.
component {
public struct function getArt(required numeric id) {
var q = new com.adobe.coldfusion.query();
q.setDatasource("cfartgallery");
q.setSQL("select artid, artname, description, price, issold, largeimage from art where artid = :artid");
q.addParam(name="artid", value=arguments.id, cfsqltype="cf_sql_integer");
var result = q.execute().getResult();
//convert the Query into a simple structure
var art = {id=result.artid[1], name=result.artname[1], description=result.description[1], price=result.price[1], sold=result.issold[1], image=result.largeimage[1]};
return art;
}
public query function getArtList() {
var q = new com.adobe.coldfusion.query();
q.setDatasource("cfartgallery");
q.setSQL("select artid, artname from art order by artname asc");
return q.execute().getResult();
}
}
Ok - so that's our old school (although nicely mobile optimized) web site. To begin the conversion to PhoneGap, I create a new file for my home page that is pure HTML, no ColdFusion.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Art Lister</title> <link rel="stylesheet" href="css/jquery.mobile-1.1.0.min.css" /> <script src="js/jquery-1.7.2.min.js"></script> <script src="js/jquery.mobile-1.1.0.min.js"></script> <script src="js/main.js"></script> </head> <body onload="init()"> <div data-role="page" id="indexPage"> <div data-role="header"> <h1>Art</h1> </div> <div data-role="content"> <ul data-role="listview" data-inset="true" id="artList"> </ul> </div> <div data-role="footer"> <h4>Raymond Camden</h4> </div> </div> </body> </html>
Notice that the layout is the same as before, but our content is gone. Previously that was sourced on the server by a database call. So how do we add this dynamic data back in? With JavaScript.
First - let's add some logic to run when the home page is created. This specific event is based on how jQuery Mobile does things, but again, you could do this without any particular UI framework.
$("#indexPage").live("pageinit", function() {
console.log("Getting remote list");
$.mobile.showPageLoadingMsg();
$.get("http://localhost/testingzone/phonegaptests/conversion/service/artservice.cfc?method=getArtList&returnformat=json", {}, function(res) {
$.mobile.hidePageLoadingMsg();
var s = "";
for(var i=0; i<res.length; i++) {
s+= "<li><a href='detail.html?id=" + res[i].id + "'>" + res[i].name + "</a></li>";
}
$("#artList").html(s);
$("#artList").listview("refresh");
},"json");
});
This code block performs a HTTP request to our server. (Note: I'm using localhost in the example above but in a real application it would be your site's domain, something.com.) I've built a new set of server-side code just to handle getting and returning data in JSON format. So there's still a server involved, but now it's simply returning data, nothing more. I loop over the result and render it out into the page.
The detail page is built much like the index page. It's a copy of the earlier version minus any code or actual content.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title></title> <link rel="stylesheet" href="css/jquery.mobile-1.1.0.min.css" /> <script src="js/jquery-1.7.2.min.js"></script> <script src="js/jquery.mobile-1.1.0.min.js"></script> </head> <body> <div data-role="page" id="detailPage"> <div data-role="header"> <h1></h1> </div> <div data-role="content" id="detailContent"> </div> <div data-role="footer"> <h4>Raymond Camden</h4> </div> </div> </body> </html>
To handle this, back in my JavaScript I added code to run when the page is loaded.
$("#detailPage").live("pageshow", function() {
var page = $(this);
var query = page.data("url").split("?")[1];
var id = query.split("=")[1];
console.log("Getting remote detail for "+id);
$.mobile.showPageLoadingMsg();
$.get("http://localhost/testingzone/phonegaptests/conversion/service/artservice.cfc?method=getArt&returnformat=json", {id:id}, function(res) {
$.mobile.hidePageLoadingMsg();
$("h1",page).text("Art: " + res.name);
var s = "<p>" + res.description + "</p>";
s += "<p>Price: "+res.price + "<br/>";
s += "Sold: ";
if(res.sold == 1) s += "Yes</p>";
else s+= "No</p>";
s+= "<p><img src='" + res.image + "'></p>";
$("#detailContent").html(s);
},"json");
});
And that - as they say - is basically it. To summarize:
- The code in the PhoneGap application is just HTML and JavaScript.
- The dynamic data from the earlier application was rewritten to expose itself remotely.
- PhoneGap then simply uses Ajax to fetch that data.
I've attached a zip of all the code used for this blog post below. If any part of this doesn't make sense, let me know, and I hope this was helpful.
Topics:
Additional Considerations When Working on Native Mobile Apps
Read what considerations are on a few executives' minds.
To gather insights for DZone's Native Mobile App Development Research Guide, scheduled for release in February, 2016, we spoke to 18 executives who are developing mobile applications in their own company or helping clients do so.
Here's who we spoke to:
Dan Bricklin, CTO, Alpha Software| Adam Fingerman, Co-Founder and Chief Experience Officer, ArcTouch | Nishant Patel, CTO and Kurt Collins, Director of Technology Evangelism, Built.io | Tyson Whitten, API Management Product Marketing, CA Technologies | Rajiv Taori, VP Product Management Mobile Platforms Group, Citrix | Zach Slayton, VP Digital Technology Solutions, Collaborative Consulting | Brad Bush, COO, Dialexa | Craig Lurey, CTO and Co-Founder, Keeper Security | Jessica Rusin, Senior Director of Development, MobileDay | Steven Jovanelly, Senior Director, Innovation Lab, PGi | Brandon Satrom, GM Developer Platforms and Tools, Progress Software | Eddie de Guia, Co-Founder and Managing Director, PubNative | Hans Ashlock, Technical Marketing Manager, Qualisystems | Mark Kirstein, Senior Director of Enterprise Software, RhoMobile | Justin Bougher, Vice President of Product, SiteSpect | Carla Borsoi, Software Product Manager and Marketing Lead, 6SensorLabs | Lubos Parobek, VP of Products, Sauce Labs
We asked these executives, "What have I failed to ask that you think we need to consider with regards to native mobile app development?"
Here's what they said:
- Be friends with a good graphic designer (UX). There's a big variation in the skills of a developer and a designer. Team up with someone that can design your front-end so you can focus on the development of the application.
- Think about what we’re doing with the data. Do we need to collect all of the data we're collecting? What are we going to do with it? How do we keep it secure? In what form do we need to serve it back up?
- How do we balance the spectrum of options and get the experience to fit together. We need to ask customers “what do you want to see?” while also realizing, like Steve Jobs did, the customer may not know what is possible.
- Open source is what developers love. Github enables you to become familiar with the technologies, collaborate via websites, hackathons provide access to APIs.
- At the network level, how devices are interconnected and the underlying network infrastructure.
- Cross-platform development tool like Xamarin enables you to write once and use anywhere by compiling code. Everything depends on the business purpose of the app.
- I'm not very familiar with hybrid but I see the opportunity of providing a base-level of functionality. Over time that will evolve and we’ll have standards - especially on Android (Amazon and Samsung) which will enable us to put more focus on the business.
- The mobile developers of today are the IoT developers of tomorrow. End user experience, minimal bandwidth use, personalization are all critical. There will be more devices like Amazon Echo with Alexa. Anything with an API is a development platform.
- Tooling. Know what's available and what problem it solves. If you find something that works, stick with it. Don't chase shiny objects, they'll waste your time. Learn what's working for others' that may be able to help with your challenges.
- The future is a good question. More platforms are coming out and everything will be connected. Amazon Echo is very cool and has a native tool kit. Google will come out with a Google Now version to compete with it. Simple to do an integration with and have a voice command tool.
- Apps that are used globally need to consider network bandwidth. Apps that work well in South Korea don’t work so well in the U.S. - or other parts of the world.
Do you have any additional thoughts about the development of native mobile apps that we didn't address in the last 10 articles?
Topics:
NATIVE APP VS MOBILE APPS VS MOBILE WEBSITES,IOT APP DEVELOPMENT,IOS,ANDROID,BIG DATA
Faster Android Emulator Has Arrived!
The Android Studio 2.0 preview of the new-and-improved Android emulator is here at last! After the beta release in November, it's been a waiting game for developers eager to try out the highly anticipated, much faster emulator.
The Android Studio 2.0 preview of the new-and-improved Android emulator is here at last! After the beta release in Novemeber, it's been a waiting game for developers eager to try out the highly anticipated, much faster performing emulator. Now with Android Studio 2.0 Preview 3, they can.
Speed Gains
So, let's get down to the nitty gritty. How fast is it?
CPU Performance
Android Studio now defaults to using CPU acceleration on x86 emulator system images. In combination with Symmetric Multi-Processor (SMP) support in Android 6.0 Marshmallow system images, the Android emulators can outperform many physical Android devices. Finally capable of multi-core support, not only do your apps and the emulator run faster in Android Studio, but common developer tasks like installing APKs are quicker as well. Also, with SMP you can test apps specific to multi-processor Android devices—a noteworthy new feature.
Android Debug Bridge
On top of faster CPU speeds in the emulator, one "under-the-hood" improvement made to Android Studio involves pushing files to your device using Android Debug Bridge (ADB). When using Android 6.0 Marshmallow and higher system images with the new Android Emulator, you can now push files across the bridge up to 5x faster than an actual device. This will help if you're pushing large application packages or files during your app development cycle.
User Interface
Still exciting, though maybe not as high in demand, there have been a fair amount of upgrades to Studio 2.0's UI.
Some of the new features available are:
- Toolbar - shortcuts for common emulator actions
- Window Zooming & Scaling - better controls for viewing projects
- Drag & Drop - easy access for installing APKs and moving files to the emulator's SD card storage
- Extended UI Controls - a range of emulator actions such as virtual calls and SMS messages, battery controls, or sending a GPS location point
So, for all those eager to start emulating, here are the details available on how to set up the new preview. Also, check out the official Android Developers Blog for more details.
Topics:
ANDROID STUDIO 2.0,EMULATOR,MOBILE,ANDROID,MOBILE APP,ANDROID APP,ANDROID APP DEVELOPER,MOBILE APP DEVELOPMENT
沒有留言:
張貼留言