Smartphone Apps- Iphone, Android, HTML5 etc.
Tagged: android, app, apps, development, Iphone
- This topic has 7 replies, 3 voices, and was last updated Feb 19, 2013, 4:41 pm by .
-
AuthorPosts
-
September 21, 2012 at 3:40 pm #15463
Andrew Boyarsky
MemberDoes anyone happen to know of any developers, either faculty, students or others in the CUNY community who are developing mobile apps for multliple platforms: Iphone, Android, HTML5 etc.?
We have a city client who is looking to develop these based on city plan documents.
Please contact me here or at andrew.boyarsky@mail.cuny.edu
September 21, 2012 at 3:58 pm #26020Christopher Stein
ParticipantAndrew,
I have an interest in mobile (I teach Media Arts & Technology) but haven’t
spent time developing a real app. If you are looking to develop for mobile
platforms I would suggest looking at platforms like Phone Gap (
http://phonegap.com/) or Sencha Touch (http://www.sencha.com/products/touch
)Best,
ChrisOn Fri, Sep 21, 2012 at 3:40 PM, commons.gc.cuny.edu <
wordpress@commons.gc.cuny.edu> wrote:September 21, 2012 at 7:43 pm #26021Suzanne Tamang
ParticipantAndrew, I’m developing an app with Sencha Touch 2 at the GC’s New Media Lab. Are you sure that a crossplatform development framework is best to create what they need? If not, what is gained through interoperability, and sleek HTML5/JS based features, can be lost in performance. That’s often unsaid or just not understood. Despite the use of this phrase, these frameworks don’t `make native apps’ — it’s more like a simulated app through a browser. I don’t know what a city planning doc is, but depending on what the content, purpose, environment, and users, crossplatform development frameworks could be a great or terrible idea.
Chris – you should try human.io from Tastylabs. From what I’ve seen it’s focused on ease of use so that non-coders don’t drown when they dive-in, and nice examples/ideas to build from for those more mobile development savvy. Still wondering why I haven’t heard about people using them yet. I think they’d be great for student projects… maybe your Media Arts & Tech class next semester 🙂
September 25, 2012 at 1:20 pm #26022Andrew Boyarsky
MemberChris/Suzanne:
Thanks for advice. I will look into these and may reach out to you to discuss what we are trying to accomplish.
September 26, 2012 at 1:16 am #26023Christopher Stein
ParticipantAndrew, you’re welcom.
Suzanne, thanks for the tip. I’ll have to look into it. FWIW Phone Gap does produce native apps. It takes the HTML5/JS stuff and converts it into native apps. Of course that means that you have to go through a process for each platform and then also go through the hassle of uploading the apps to the respective stores. Also, for certain phone features I believe that you have to still write code in the native dev langage. So, it’s still like you said dependent on what exactly it is that you’re developing.
September 26, 2012 at 4:16 am #26024Suzanne Tamang
ParticipantChris and Andrew – there is a Mobile Technology Research Group on the CUNY Commons. I don’t think I’ve ever received an email from it, but as more people are interested, it could be nice to breath some new life into it! And perhaps another nice forum for this type of discussion too.
Chris, that is interesting. From what I read about PhoneGap it is a Web app, and browser-rendered (like Sencha). A truly native apps isn’t browser dependent. If the host isn’t a browser, how is an interpreted language writing compiled code that’s mindful of the os/machine language? Is it a hybrid framework?
All of these Web apps entail a similar deployment process for ios customization and app marketplaces. That does not mean it is making a native app, it is rather making an application that is native-app-like.
Also, here’s a recent post with some thoughts from Mr. Z on his Web-app regrets, and some kudos for native development. Sadly (I’d love to be convinced otherwise), if performance is key (and you have the resources to develop multiple native apps), I’ve seen more and more that says go native, and steer clear of the bandwagon.
September 26, 2012 at 11:17 am #26025Christopher Stein
ParticipantSuzanne, I’ll post this in that group too. I have to admit I haven’t gotten
past the point of looking at mobile technologies yet. I’m not sure when I’m
going to get the time to really get my hands dirty and develop one. If you
want to know more about the technology behind PhoneGap, it’s called Cordova
and is open source: http://incubator.apache.org/cordova/. Perhaps native
was the wrong word to use. I think many are calling apps made by tech like
PhoneGap hybrid. As I understand it PhoneGap is essentially a JavaScript
library coupled with wrappers written in native code for each of the
platforms it supports. You write your code in JS and then the native
wrappers work with the particular OS to get everything running. Because
there is that translation I’m sure that it means that there is a
performance drain, much like Java programs running on the virtual machine.
For apps that are very dependent on the speed of the code executed (like a
game or image editor) this might be a problem. For other kinds of apps it
may not be a problem at all.The main reason people are doing them is that web developers can leverage
their existing skills and you don’t have to write ground-up native apps for
iOS, Android, Windows Phone, Blackberry… For companies like Facebook who
have a lot of money and a lot of users and a lot of data then yeah, it
makes sense to write all of those applications. For educational based apps
where there is no money but a lot of different student devices to support,
and especially those apps that are mostly displaying textual information,
then the hybrid ones are probably best. I also personally believe that the
performance of HTML5/CSS3/JS apps will continue to get better.For other people who might be reading this and a little confused we are
talking about different ways to make an “app” available to a mobile user.
There are roughly three ways (IMHO):
1. Web Based. You make a web page that is optimised in some way for mobile
viewing. The user goes to the browser in their mobile device and then uses
the app. No permission needed to do this. Downsides are that the person
needs Internet access to use the app and performance is slower compared to
the other options. There are development platforms you can use to make your
app look more like a native one.2. Fully Native. You write the app in the programming language supported
the the OS. Package it and then submit it to the store for that OS. Users
will have to visit the store, download the app and then use it. This is the
best way to make sure that your app runs fast and can take advantage of the
phone’s capabilities. Data is stored on the phone and so it can be used
without Internet connection Downsides, you have to write the code in
different languages for each platform and you have to be accepted into the
store for deployment. This also usually means longer development times and
higher development costs.3. Hybrid. You write your code once, usually using HTML5/CSS/JS, and then
use a special tool like PhoneGap/Cordova to package that code into native
packages for each of the different OS’es. This way you don’t have to write
different code for each platform. Downside, not all of the features of all
phones are supported in this way. The code does not run as fast as code
written in the native OS language. There are the same downsides as a fully
native app, you still have to submit the app to the various stores for each
OS and get them approved and the user will then download and use the app.Best,
ChrisOn Wed, Sep 26, 2012 at 4:17 AM, commons.gc.cuny.edu <
wordpress@commons.gc.cuny.edu> wrote:February 19, 2013 at 4:41 pm #26026Andrew Boyarsky
MemberChris/Suzanne:
We are getting ready to send out inquiries on developing a mobile app. As i am unfamiliar with the territory, do you have any time in the next week or so to discuss what we are looking to accomplish in the first and then second round of development and what path we might take.
Please let me know.
thanks,
Andrew
-
AuthorPosts
You must be logged in to reply to this topic.