HTML5+svg[2]+css3+ecmascript5+domL2/L3

építsünk egy sokkal szebb webet

PhoneGap: avagy a mobil fejlesztés leghatékonyabb HTML5/JavaScript-ben?

25 hozzászólás


Követő bejegyzések: Cordova (alapmotor az Apache-től) és PhoneGap (szolgáltatásokkal bővített Adobe disztribúció) (2012. március 21.)
– Microsoft and jQuery Mobile, PhoneGap [Oct 13 – Dec 19, 2011]
– PhoneGap 1.2 (2011. november 16.)

Kiváncsian várom a Magyarországi Web Konferencia (program, regisztráció) HTML5 fejlesztés Windows Phone Mangora című előadását. Vajon mit hoznak ki a HTML5 nyújtotta lehetőségek mobil fejlesztésekben való kiaknázhatóságából? Az foglalkoztat, hogy meddig lehet ebben eljutni. Ezért néztem körül a hálón, és azt találtam, hogy ma már bizony ez a leghatékonyabb módja a mobil fejlesztésnek. A címben ez az állítás még kérdésként jelenik meg, amire az igenlő választ majd az alábbiak adják meg.

Először is mostanra érett be egy PhoneGap nevezetű, én azt mondanám middleware, (ez a termék már decemberben előjött nálam) fejlesztői szerint azonban:

PhoneGap is a cross platform native development framework. Enables you essentially write native applications for various mobile phone platforms with HTML5, JavaScript and CSS.

Ezzel a meghatározással kezdődik (Dave Johnson, Nitobi CTO) az alábbi videó:

PhoneGap – An Open Source Mobile Framework [July 28, 2011]

http://www.phonegap.com – PhoneGap is an open source development tool for building fast, easy mobile apps with JavaScript. If youre a web developer who wants to build mobile applications in HTML and JavaScript while still taking advantage of the core features in the iPhone, Android, Blackberry, WebOS, Symbian, Windows Phones and Bada SDKs, PhoneGap is for you. There ar more than half million downloads of the framework today.

A Stack Overflow-n megfogalmazott How to start with phonegap development? [Sept 29, 2011] kérdésre egyenesen így válaszolt valaki:

You don’t need JavaScript for a basic Phonegap App. What they do is basically translate a WebPage to a App for the desired Plattform. Therefore you just need to know as much Javascript as your app needs.

Afaik you can also use frameworks like jQuery. More tutorials are available here: http://wiki.phonegap.com/w/page/35501397/Tutorials

Here on UI Development: http://wiki.phonegap.com/w/page/36767911/UI%20Development%20on%20PhoneGap

And there is many more. Maybe you can look into general Javascript tutorials first if you look for a special effect or so.

Vagyis még a JavaScriptet sem kell valakinek ismernie ahhoz, hogy elkezdje kiaknázni a PhoneGap lehetőségeit, és csak akkor kell ennél több, ha többre van szükség. Ekkor is ott vannak a népszerű JavaScipt keretrendszerek, mint a jQuery (pontosabban – tenném én hozzá – a jQuery Mobile), amelyek egyedi interfész kialakításánál szükségesek, míg igazi, kemény JavaScript programozásra például speciális effektusoknál van csak szükség, ha ilyeneket szeretnénk a készülő alkalmazásunkban.

1. No de hogyan lehet JavaScript írás nélkül már alkalmazást készíteni? No meg hogyan, milyen értelemben lesz az így elkészült szoftver “natív”, JavaScript ide, vagy oda? Vizsgáljuk meg ezeket az alapkérdéseket:

Brian LeRoux (Senior Architect, Nitobi) egy hete az Untappd alkalmazásra hívta fel a figyelmet, mondván ez az ő személyes favoritja. Az Untappd We’ve Gone Native! [Sept 30, 2011] bejegyzése ugyanis arról számolt be, hogy az eddig tisztán webesként működő mobil alkalmazásnak elkészült az ún. natív verziója. A sörivás, sörmárkák és sörözők kapcsán szerzett élményeket lehet megosztani közösségi jelleggel másokkal, illetve mások tapasztalatai alapján tájékozódni (ld. What is Untappd? [March 22, 2011] illetve Untappd delivers a new mobile, web-based social network for beer drinkers and enthusiasts [press release, Oct 22, 2010]). Úgy tűnik az üzlet ebben a cég számára az így gyűlő információk üzleti szolgáltatása a sörmárka előállítóknak és sörözőknek (ld. Business Opportunities).

Az új, kétplatformos (iPhone és Android) “natív” alkalmazás, kisebb nagyobb problémáktól eltekintve, már jól működik. Fejlesztői szerint:

These apps feature some much needed speed enhancements, interface changes, and some awesome new features that we think you’re going to love. … 1. Share your experience with photos2. Notification center3. New navigation interface4. Speed enhancements … We took our old app, redesigned it and touched it up and basically wrapped in a PhoneGap web wrapper. Great solution!

azonban jött egy ilyen észrevétel is:

Max Howell: Nice “Native” app. All you have to do is hold down the “drink up” button on iPhone to get the default UIWebView action sheet proving the whole app is just a big UIWebView container. Try again please.

vagyis, hogy miként lehet natív alkalmazás az olyan, ami UIWebView alapú? Erre jön is a beismerés és egyfajta magyarázkodás:

Hey Max – I don’t think its a surprise that our app is a UIWebView. We made a very popular web app – and we are not iOS and Android developers – so this was a natural choice using PhoneGap. We try to mimic the same look and feel of our Web apps in our Native apps.
I’m sorry that your not happy with our product – but this a first step into get our product out in the store with the intent to the public aware of Untappd.
Thanks,
Greg

vagyis nem lévén saját kódú (azaz Objective-C-s illetve Java-s) iOS és Android fejlesztők, hanem webesek, no és mivel a másik két mobil platformon (BlackBerry és Palm Pre) változatlanul a webes alkalmazást használják az emberek, azért UIWebView alapú az iPhone és az Android változat.

1.1 De mi is ez a UIWebView? Mennyire webes, vagy nem webes? Egyáltalán miről van itt szó, mitől “natív” ez?

Az első választ az iOS Developer Library-ben találjuk, miszerint:

Available in iOS 2.0 and later. … You use the UIWebView class to embed web content in your application. To do so, you simply create a UIWebView object, attach it to a window, and send it a request to load web content. You can also use this class to move back and forward in the history of webpages, and you can even set some web content properties programmatically.

Vagyis a natív, Objective-C-ből használható objektumról van szó (ennyiben máris egy “natív” tulajdonság jelenik itt meg), ami web tartalom beágyazására szolgál, azaz minden, ami a futáshoz kell az iPhone-on van, ezért az ilyen, webes tartalmat is magában foglaló alkalmazás az AppStore-ból is működik, ami további “natív” tulajdonság. Ld. a UIWebView Tutorial [Aug 19, 2008] egyszerű példáját, ami azt is megemlíti, hogy a Safari böngésző használatára sincs szükség. Miért? Idézet a WebKit or not to Webkit within your iPhone application? [Nov 10, 2008] című, szintén korai cikkből erre vonatkozóan:

… on the iPhone there is this nifty object called UIWebView. Otherwise known as WebKit. Otherwise known as an embedded browser in your iPhone app.

And if you want a sexily awesome looking UI view, like the Today view of the Surf Report app (see right or free on AppStore) that was released on the AppStore recently, then the WebKit is just the best thing since the electric bread slicer for speed of development.

Holy grail of iPhone development?

Well, that’s what we thought. When I chatted with Dan Grigsby last week I mentioned there were good and bad things about the WebKit within an iPhone app.

This article is about good and bad things. The pros and cons. How we managed the integration of the two code-bases. And the answer to the big question: Would we do it again?

Would we do it again?

Yes.

The WebKit isn’t the holy grail for non-Objective-C developers, but if your grand-poobar level skills are in JavaScript and HTML, and your Objective-C/iPhone skills are still catching up, then its a wonderful prototyping platform. Especially for static, complicated displays of data. Especially if that data includes HTML content from an external feed which needs to be rendered.

Vagyis az egykoron a Safari-ból leágaztatott, beépített WebKit böngészőmotor alapozza meg egy UIWebView objektum működését, azaz teszi lehetővé az adott UIWebView objektumba ágyazott webes tartalmak megjelenítését az iPhone képernyőjén. Ebben az értelemben ezzel a beágyazott webes tartalom “natívvá” válik. Újabb “natív” tulajdonsággal bővülnek tehát az eddigiek. Mi több a fenti cikk azt is megállapítja, hogy:

You can invoke JavaScript code within the WebKit via your native Objective-C code.

[webview stringByEvaluatingJavaScriptFromString:@"loadData({some: 'data'})"];

The JavaScript bridge is one directional. From Objective-C/UIKit you can invoke JavaScript upon the WebKit and henceforth do wonderful things (as per example above).

From JavaScript you have no native nor nice way to invoke methods on Objective-C objects, like you can in the Cocoa implementation of embedded WebKits.

azaz at Objective-C-ből elérhető a JavaScript kód (vagyis ez egy újabb “natív” tulajdonság), bár – akkor ezt ők így találták – fordítva ez nem igaz.

Mivel a WebKit-et másutt is használják (Android, Symbian, Palm/HP WebOs) egyfajta egységes HTML/JavaScript/CSS kód lehetősége is van ezáltal, no és persze akár a UIWebView-hoz hasonló funkcionalitást is ki lehet alakítani más rendszerekben (olyan mértékben, amennyire ezt az esetleges Apple szerzői jogok lehetővé teszik, én nem tudom), ami még nagyobb átjárhatóságot tesz lehetővé az érintett mobil platformok között. (A PhoneGap-esek általában WebView-ról beszélnek az eszköz saját kódjának oldalán, pl. az Android Java esetében, úgy tűnik egyfajta koncepciós hivatkozásként.) Mi több az adott platform saját kódja és a JavaScript közötti átjárhatóságra is vannak lehetőségek.

No itt érkeztünk el a PhoneGap alapvetéséhez, ami piaci sikerét is lehetővé tette. Bár Dave Johnson PhoneGap Native Bridge [Aug 13, 2010] bejegyzése több, mint egy évvel ezelőtti állapotot tükröz, ez az egyedüli, amely technikailag is érthetővé teszi ezt. Egyedül az iOS és Android megoldásokat idézzük itt (és nem idézzük az akkori BlackBerry 4.x, BlackBerry WebWorks, Qt, Windows Phone 7, WebOS és WRT [Symbian] megoldásokat):

The “native bridge” is the secret sauce of PhoneGap and is what allows JavaScript in an embedded browser talk to native code and vice-versa.

On every platform we do this differently depending on what features that native browser has. Here is the list of platforms and how we do it.

iOS: To communicate from JavaScript to native we call window.location = “gap://Class.method/args” and then intercept the url in native code and parse our the parameters. The class / method is then dynamically loaded / called. To call JavaScript from native we use UIWebView.stringByEvaluatingJavaScriptFromString.

Android: Communication from JavaScript to native is achieved by overriding the JavaScript prompt function in the Android native code and the message passed is much like that used in iOS. We used to use WebView.addJavascriptInterface to add Java objects directly to the JavaScript sandbox but that was causing some devices to crash with Android 2.3. To call JavaScript from native we currently use WebView.loadUrl(”javascript:…”) but that has some problems so we are soon moving over to polling a Java message queue calling a local HTTP server via a long-lived XHR connection.

Vagyis egyfajta hekkeléssel kialakított híd (bridge) megoldja, hogy egy beágyazott böngésző segítségével futó JavaScript kód az adott platform saját kódjával kommunikálni tudjon, és fordítva. A hekkeléssel elért megoldás attól függ, hogy milyen sajátosságai vannak az adott platform saját böngészőjének. Architektúrálisan ez a következőt eredményezi (PhoneGap for Engineers [June 9, 2011]):

PhoneGap Architecture by PhoneGap -- 9-June-2011

Középen látjuk ezt az elvi hidat, melynek döntő jellemzője még, hogy csupasz (chromeless), csak megjelenítési gépezetként működő böngészőt (mint a WebKit) feltételez az eszközön lévő, szabványos webes (HTML, JS, CSS) tartalmak megjelenítéséhez. Az eredmény ebben az elvi megoldásban nem csak okostelefonokon, hanem tableteken, asztali gépeken, TV-ken, autókban és sok más helyen való alkalmazhatóságot vetít előre, hiszen csupasz és szabványos böngészővel ma már ezek az eszközök is rendelkezhetnek, és “a határ a csillagos ég”. Amit ezen az ábrán nem látunk az a híd JavaScript és saját eszközkód közötti “átjárást” biztosító szerepe, de ez az eddigiekben technikailag is be lett mutatva.

1-es kérdésünkből már csak a “hogyan lehet JavaScript írás nélkül már alkalmazást készíteni?” nem került megválaszolásra. Ez roppant egyszerű, csak az alábbi videót kell megtekintenünk:

How to program a UIWebView [Oct 28, 2009]

Background: … I’m Also a kid 13 years old ,,, but I’ve got the same as @coulton94 I’m connected to the internet and al that stuff you know But it’s still not loading the screen! Please help me! Because I’m making an app and want to send it as soon as possible to Apple! .. you forget to connect your outlet with the UIWebView control in interface builder, this is the problem. …

Vagyis itt azt látjuk, hogy egy mindössze 13 éves gyerek minimális segítséggel (ide csak némi kivonatot másoltunk az ezt illusztráló kisérő szövegből, míg a videó már a képességbeli eredményt mutatja) elsajátította a UIWebView használatát. Ha van egy működő webalkalmazásunk (amit sok JavaScript nélküli eszközzel elő tudunk állítani), akkor azt roppant könnyen iPhone alkalmazássá tudjuk alakítani a UIWebView és az Apple interface builder-e segítségével.

Persze a fenti Untapped alkalmazás “natív” változatához már kellett úgy a PhoneGap, mint a JavaScript programozás. Mégpedig azért, mert a “natív” változat egyik funkcionális bővítménye a webeshez képest az, hogy az adott sörözési élményről készített fotót is közzé lehet tenni. Ehhez pedig az iPhone vagy az Android telefon beépített fényképezőgépét magából az Untapped alkalmazásból kell tudni használni. Ebből következik az alábbi kérdés:

2. A PhoneGap segítségével hogyan fér hozzá a JavaScript alkalmazás az adott mobil eszköz natív képességeihez, mint például a beépített fényképezőgép használat (hogy ezzel további “natív” lehetőségekkel legyen bővíthető az eredetileg webes program)?

Mivel a PhoneGap eredendő, “híd” funkciójának megfelelően technikailag megoldott a JavaScript és az adott platform saját, natív kódja közötti kétirányú kommunikáció, a válasz ezek után roppant egyszerű:

A piacot alakító mobil platformok eszközfunkciói elég közel állnak egymáshoz, és így ki lehet alakítani egy egységes Device API rendszert, ami – megfelelő implementációk révén – egyúttal a többplatformos JavaScript kódolást is támogatja (mint az Untapped “natív” változatához szükséges, beépített fényképezőgép funkció használatát). Ehhez a Device API-kat alapos és körültekintő munkával tervezni és implementálni kellett a szintén nem kevés munkával prioritási rendbe sorolt platformok között. Mindehhez egy PhoneGap menetrend (roadmap) szerint kellett tevékenykedni az elmúlt másfél évben, minek eredményeként előáll majd egy, az alábbi ábrán látható tervezett állapot (ez az ábra egy július 29-i prezentációból való, amit majd nevesítek a későbbiek során, és szólok a tervhez képest eltérő készültségi állapotról már addig is, menet közben):

PhoneGap Roadmap from Plan to Delivery (IBM) -- 29-July-2011

Ha rákattintunk a fenti képre, akkor hozzájutunk annak legnagyobb felbontású változatához, ami többé-kevésbé már olvasható lesz. Ehhez képest a PhoneGap pillanatnyilag a következő készültségi állapotot mutatja webhelyén a Supported Features címszó alatt:

PhoneGap Supported Features -- 4-Oct-2011

Megjegyzés:A táblázatban az “OS 4.6-4.7 / 5.x / 6.0+” a BlackBerry OS (RIM) különböző változatait jelenti.

Itt olvashatóan látjuk a megvalósított Device API-kat, mégpedig az egyes platformok vonatkozásában. Észrevehető, hogy az utóbbiak közül hiányzik a Windows Phone 7 (ami az előző ábrán még szerepelt), aminek egyszerű oka van. Íme egy bejelentés: Announcing PhoneGap for Windows Phone Mango [Jesse MacFadyen, Senior SE, Nitobi, Sept 8, 2011], amiből a következőket érdemes idézni:

Over the last month and a bit, Nitobi has been working closely with Microsoft to bring PhoneGap to WP7 devices. I am happy to say that it’s now here, and ready for beta exposure.

Our starting point was the excellent work of Matt Lacey, who created the initial project and did the initial exploration of device functionality. The upcoming Windows Phone Mango update to devices brings a rich set of HTML5 features and IE9 to the device.

Thanks to Microsoft sponsorship, Sergei Grebnov has been making contributions to the code and has implemented the MediaCapture and Camera APIs. This is Sergei’s first foray into PhoneGap, but he has proven to be a valuable asset to the project and was up to speed quickly.

Nitobi has dedicated two developers to the project, myself and Herm Wong. We’ve been busy dusting off our Sliverlight+C# skills and implementing the other APIs. ( the infamous Shazron has also jumped in just this week )

What You’ll Need to Get Started

Where Are We ? What APIs Are Done?

Here’s an overview of where we’re at:

  • Accelerometer
  • Camera
  • Compass (unit testing is waiting on us having a device that supports compass)
  • Contacts
  • Events (partial, still underway)
  • GeoLocation
  • MediaCapture
  • Connection
  • Notification

These have all been implemented per the spec, and function as expected with some quirks being added to the documentation as you read this.

The ‘deviceready’ event is fired on startup, and like other device platforms, is the signal that you can begin making PhoneGap API calls.

The GeoLocation API did not require any work, as IE9 implements the spec as defined by W3C.

Still to come :

  • File
  • Storage

How Does it Work? A peek under the hood.

Gotchas + Known Issues

Reporting issues, tracking progress and keeping up to date.

Will PhoneGap for WP7 support plugins?

This was a key focus, as keeping the architecture plug-able is a primary concern, and in my view, where the real power lies.

PhoneGap-WP7 maintains the plugability of other platforms via a command pattern, to allow developers to add functionality with minimal fuss, simply define your C# class in the WP7GapClassLib.PhoneGap.Commands namespace and derive your class from BaseCommand.

PhoneGap exec works in exactly the same way as other platforms :

PhoneGap.exec(callbackSuccessFunction,callbackErrorFunction, PLUGINNAME, PLUGINMETHODNAME, paramObj);

What is Left to Do? How can You Contribute?

Sergei has begun working on the File API, so you can expect full file access to create, modify, delete files as well as upload/download to/from a server.

I am busily trying to wrap up some of the life-cycle events (Events API) so your application can be notified when the app is pushed to the background. I will be looking into exposing mouse events to JavaScript shortly after that.

Vagyis szeptember 8-án elkészült a WP7-es PhoneGap publikus béta változata annak következtében, hogy július vége óta a Microsoft-tal szoros együttműködésben, és az ő finanszírozásában, két Nitobis fejlesztő és egy Microsoft-os tudott ezen teljes időben dolgozni, ráadásul nem a nulláról indulva, hanem az utóbi időben Windows Phone 7 szakértőként sok helyen szereplő Matt Lacey egyszemélyes, korábbi munkájára alapozva mindezt (erről tavaly augusztus és november között megjelent információk vannak az illető blogján). Ezért más, jóval bővebb a mostani funkcionális lefedettség, viszont még csak átmeneti, “béta” állapotban, tehát nyilván ezért nem találjuk meg a termék Supported Features címszava alatt.

Lásd továbbá:

… Port the app to iOS, Symbian, BlackBerry, Windows, WebOS, & Bada … Don’t worry if you don’t know Objective C, Java, etc. All you need to know is HTML5, CSS3, and JS. It’s really simple to write these apps. …

Mindez jól példázza a PhoneGap fejlesztés gyakorlatát is: tipikus nyílt forráskódu projekt, mely egy idő után elnyeri az érintett és érdekelt nagy játékosok pénzügyi támogatását. Emellett látunk mást is a közleményben, ami az alábbi kérdéseket veti fel:

3. Miért látunk most szeptemberben némileg eltérő Device API megnevezéseket (pl. Network helyett Connection), illetve eddig nem szereplőket (pl. Events)? Mit jelent az, hogy a GeoLocation API esetében semmilyen implementációra nem volt szükség, mondván az IE9 szabványosan (W3C) implementálja azt? Hogyan befolyásolja a PhoneGap további alakulását más Device funkciók W3C-n belüli szabványosítása? Egyáltalán mi a PhoneGap és a W3C kapcsolata? Továbbá: milyen pluginokról van ebben a közleményben szó, és mit jelent ezek primér volta? Elgondolkozva a közlemény megfogalmazásán még az is felmerül az emberben, hogy mi köze lehet ezeknek a plug-in-oknak a már korábban jellemzett híd (bridge) technológiához és persze a PhoneGap-es fejlesztés “natív” mivoltához?

Túl sok kérdés egy menetben való megválaszoláshoz? Egyáltalán nem, mindjárt meglátjuk, hogy miért:

PhoneGap 1.0 Released Today at PhoneGap Day in Portland [Nitobi press release, July 29, 2011]

… Today’s major release puts the focus on accessing native device APIs, which is new ground for the web. Other improvements include:

* Overall API stability and “pluggable” architecture

* W3C DAP API compatibility

* Contacts API

* Remove debugging tools

Today’s release also includes a new unifying bridge interface that makes adding platforms and platform extensions easy. Plus, developers will be pleased to see that the plugin development process has been simplified. …

Vagyis a W3C DAP API-val (eredetileg: Device API and Policy Working Group, mely nyár óta Device APIs Working Group) már a július végi 1.0-ás változat kompatibilis volt (ilyen például az itt jelentősen feljavított PhoneGap Contacts API, ami jelenleg “Last Call” fázisú a W3C-nél). Az együttműködés tehát szoros. Emellett vegyük észre egy új, “egyesítő” híd interfész megjelenését, ami az újabb platformokkal való bővítést és a meglévők kiterjesztését könnyíti meg. Továbbá a “plug-in”-olható architektúra és a könnyebb plug-in fejlesztési folyamat bevezetése szintén jelentős előrelépések.

roadmap-planning [Brian LeRoux, Sept 30, 2011]

Sept 30 – 1.1.0

  • plugins (discussion on Planning: Plugin Packaging)
  • security: child browser investigation / oauth support
    • Android (Simon)
  • performance: first benchmark(s) / resource profiling hooks / capacity tests (maybe identify flagship devices!)
  • cmd line scripts for: build, debug, emulate, release, create, log, test
  • bundle phonegap/wp7 in the download ( FileAPI, MouseEvents, Storage, Template + BuildScripts )

2.x – Summer 2012 – unscheduled

Mint itt látszik a szeptember végi 1.1-es változat a plug-in-ok kérdését végképp helyre tette, továbbá a PhoneGap Windows Phone 7 Mango-s változata része lett a letölthető csomagnak, ráadásul megjelennek benne (nem tudni, hogy még csak Béta állapotban-e) az eddig hiányzó File és Storage API-k, valamint az Events API-ból eddig hiányzó egeres rész. A jövő nyárra elképzelhető 2.x-es PhoneGap változatban újabb W3C-s API-kkal számolnak (Calendar, Messaging), illetve egy kizárólag architektúrával, azaz egy olyannal, ami lehetővé teszi a jelenlegi, előre kiépített API-k (azaz Device API-k) nélküli szoftver kialakítást. Tehát a plug-in-ok koncepciója ezzel jut majd el a saját, végső kifejletéhez.

Mindezt – a megfogalmazódott kérdések további megválaszolásának alátámasztására – kiegészíteném az alábbi táblázatos infomációkkal:

Saját összeállításom (a képre klikkelve is előjön egy PDF változat, melyben lehet tovább klikkelni):

PhoneGap Release Cadence information compiled by Sandor Nacsa -- 6-Oct-2011

Vagyis a fentiekből jól látszik hogy a korábban bemutatott Supported Features még a 0.9.5-ös változatnak felel meg, míg a jelenlegi, 1.1.0-ás változat az alábbi (innen rögtön lehet klikkelni, ha valakit a további részletek érdekelnek, a dokumentáció komplett és napra kész):

PhoneGap 1.1.0 API Reference [Oct 1, 2011]

Accelerometer Tap into the device’s motion sensor.
Camera Capture a photo using the device’s camera.
Capture Capture media files using device’s media capture applications.
Compass Obtain the direction that the device is pointing.
Connection Quickly check the network state, and cellular network information.
Contacts Work with the devices contact database.
Device Gather device specific information.
Events Hook into native events through JavaScript.
File Hook into native file system through JavaScript.
Geolocation Make your application location aware.
Media Record and play back audio files.
Notification Visual, audible, and tactile device notifications.
Storage Hook into the devices native

Ezután már semmi mást nem kell tennünk, mint ide másolni a jelenlegi plug-in koncepcióra vonatkozó alapvető tudnivalókat, ahogyan azok nyáron publikálva lettek:

PhoneGap Plugins [Dave Johnson, July 29, 2011]

PhoneGap has two components

  1. PhoneGap JavaScript API which exposes native functionality to the javascript running in the Browser (Some kind of WebView)
  2. Platform Specific Native Code which is involved from the PhoneGap JavaScript API

All this is fine, when we want to do generic things like

  1. Access Geo Location from the PhoneGap JavaScript API
  2. Access Contacts from the PhoneGap JavaScript API
  3. Invoke a Call
  4. etc

More or less we are exposing common Phone functionality to Javascript.

Limitations

(Heavy Weight Lifting, Background Processing, Complex Business Logic)

Although, Javascript has become 100x faster in last few years, it still would not be able to compete with the heavy weight lifting the native code can achieve. Also if we want to do some Background Processing (eg Background Services in Android), Javascript at least right now can not achieve it. Similarly, if we implementing a very Complex Business Functionality, a preference would be given to the native language.

Say for example, If you want to implement a DropBox client using PhoneGap. DropBox client does heavy weight lifting by being continuously in the background, listening for file changes and synching file changes. Such Operation can not be done by PhoneGap’s APIs.

For such Heavy weight Lifting things, its best to delegate the responsibility to native code.

Solution

(Extend PhoneGap Framework)

The solution to go beyond is natural, do what PhoneGap did to expose the common Phone functionality to Browser code (Javascript).

This is done in following manner

  1. Have a Custom Native Component.
  2. Have a Custom Javascript API

Note this native component would be built for each platform you plan to support. All these native components needs to adhere to the Custom JavaScript API.

Overall Architecture

PhoneGap-Plugin by Dave Johnson -- 29-July-2011

In order to write PhoneGap Plugin for each Platform, you have to write two components

  1. JavaScript Component, which will expose the Custom Native Component
  2. Native Component, which does the heavy lifting

Vagyis a plug-in architektúra azért lett kialakítva, hogy ne csak a mobil eszközök Device API-on keresztül megnyilvánuló funkciói legyenek (egyébként egységes módon, a W3C-vel szoros együttműködésben való kialakításban) elérhetők a JavaScript kódból, amit a beágyazott böngésző hajt végre, hanem az adott eszköz, platform saját kódjában írott modulok is elérhetők legyenek JavaScript-ből. Erre azért van szükség, mert hiába lett néhány év alatt százszor gyorsabb a JavaScript, bizonyos igényekhez a platformon futó saját kóddal tudunk csak elérni kellő teljesítményt. Itt Dave Johnson még a háttérfeldolgozás és az összetett üzleti funkciók, mint hasonló igények eseteit is említi.

Miután egy ilyen plug-in architektúra bevezetésével minden akadály elhárul a PhoneGap előtt a többféle platform minden natív lehetőségének tetszőleges kiaknázására, és ezzel teljes mértékben igazolttá válik a Nitobi-sok (de mondhatnánk PhoneGap-eseket is) azon állítása, hogy képesek a HTML5/JavaScript alapú fejlesztéseket bármilyen, az adott platform saját környezetében végrehajtott fejlesztéssel egyenértékűvé tenni (ők úgy mondják “natívvá” tenni), nos ezután már csak egy, végső kérdéscsoport marad:

4. Jelenlegi 1.1-es változatában, illetve a jövő nyárra tervezett 2.x-es változatnak megfelelően mit is kínál a PhoneGap, és nem csak az “egyszerű”, fogyasztói jellegű fejlesztésekhez (mint, amilyen Untappd példánk volt), hanem a legigényesebb vállalati fejlesztésekben is? Másként fogalmazva: képes-e a PhoneGap a lehető legszigorúbb elvárásoknak is eleget tenni, beleértve a jelen tényfeltáró elemzés címében szereplő kérdést is, hogy segítségével elérhető-e a HTML5/JavaScript-ben végzett mobil fejlesztés minden másnál nagyobb hatékonysága?

Az alábbi videó felvétel a lehető leghitelesebb módon ad igenlő választ ezekre a kérdésekre:

PhoneGap Day 2011 – IBM, PhoneGap and the Enterprise by Bryce Curtis [Aug 10, 2011]

Bryce Curtis from IBM talk’s about IBM, PhoneGap and the Enterprise at PhoneGap Day on July 29th, 2011. He is a software developer for web technologies in the Mobile and Emerging Technologies space under the Strategy CTO of the IBM Software Group (that CTO happens to be an IBM distinguished engineer as well).

Az előadás slide-jait a SlideShare-en lehet elérni.

A számunkra legfontosabb IBM megállapítások sorát kezdjük először azzal az ábrával, mely a beágyazott videó nyitó képernyőjén is látható (a korábbi PhoneGap menetrend (roadmap) ábra is innen való):

PhoneGap Architecture by IBM -- 29-July-2011 -- modules instead plug-ins

Tehát egy teljesebb architektúrális képet közvetít az IBM, amihez különösebb magyarázat sem kell, hiszen az eddigi szöveges és grafikus magyarázatokat összegzi lényegre törő módon ez az ábra.

Az előadás egy másik ábrája már komoly újdonságtartalmat is hordoz:

PhoneGap Hybrid Approach compared to the Web and Native (IBM) -- 29-July-2011

Itt azt látjuk, hogy valódi értelemben a PhoneGap alapú fejlesztést és magát a PhoneGap segítségével készített szoftvert igazából hibrid-nek (és nem natív-nak) kell nevezni. Mivel mind a webes alkalmazásfejlesztés, mind a natív alkalmazásfejlesztés előnyeit a lehető legkedvezőbb módon ötvözi, az így végzett fejlesztés hatékonysága mindkettőnél jobb, ha a baloldalon szereplő összes tényezőt figyelembe vesszük. (Természetesen ha valakinek a hatékonyság mindössze egy vagy néhány baloldali tényezőt jelent, akkor rögtön tagadja állításomat. Tipikus eset a fejlesztő kisvállalkozóé.)

Fontos megjegyzés: A hatékonyság fontos megalapozója az alkalmazott, “felsőbb szintű” JavaScript keretrendszer is. Mivel JavaScript keretrendszerek összevetése (2011. március 16.) című elemző kigyüjtésem jól tükrözi ezek magas fokú hatékonyságát, ráadásul ebben a tekintetben a PhoneGap teljesen nyitott, ezt a részét a hatékonyságnak itt nem kell vizsgálnom. Az IBM egyébként a Dojo Mobile-t választotta, ami teljesen megfelel a márciusban találtaknak.

Még egy részletet ragadnék ki az előadásból. A legelején, a “Mobile Landscape” tárgyalásánál (a felvétel [2:10] részénél, illetve 4. ábra) elhangzik ([3:06]-nál), hogy míg a múltban éveket tett ki az üzleti alkalmazások élettartama, addig ma ez mindössze 3 hónap (értve ezalatt azt, hogy változatlan funkcionalitást használ a felhasználó), és a fogyasztói alkalmazások – szinte el sem hihető, mondja az előadó – esetében ez még ennél is kevesebb, csak 3 nap. Sokan csak egyszer próbálják ki a szoftvert. Mindez igen komoly változás.

Én úgy gondolom, hogy ezt a körülményt is figyelembe véve rendkívüli hatékonysági előnyöket kínál a PhoneGap megközelítés. Ráadásul még abban az esetben is, ha egy szoftver cég “csak” iPhone-ra fejleszt. A tisztán Objective-C alapú fejlesztést nagyon megdrágítja, hogy a ma már sokféle iPhone közötti különbségeket folyamatosan figyelembe vegyék egy átlagban 3 napos élettartammal bíró verzió kidolgozásánál.

Ajánlatos ilyen irányban tovább vizsgálni a PhoneGap előnyeit. Ehhez adalék egy másik IBM-es videófelvétel, ami ráadásul mindössze 3 és fél perces:

What options do developers have for creating mobile apps?  [Andy Dingsor, Advisory Software Engineer, IBM, Aug 4, 2011]

Andy Dingsor, IBM Software Engineer with the Web 2.0 and Mobile Feature Pack, discusses the options and tradeoffs that software developers have when building a mobile app.

Hybrid Mobile Applications [IBM DeveloperWorks, Web 2.0 and Mobile Blog, July 7, 2011]

Without a doubt, based on last week’s most popular blog entries & from the many questions we receive, PhoneGap, and the hybrid model approach for building mobile applications is a very popular topic, and one that is raising a lot of interest.

Someone who’s also a big fan of this open source technology is Andy Dingsor, one of our Web 2.0 & Mobile application services developers.

When asked about the different options that exist to developers today for creating mobile apps, Andy quickly explained why he prefers the hybrid approach in some cases and why he thinks this solution can offer the best of both worlds.

He also cited a hybrid approach as an alternative for developers to use for uploading their mobile applications into an AppStore or Android market.

In fact, Andy also contributed a short tutorial which demonstrates how easy it is to build a hello world type of application, by simply following instructions directly from the PhoneGap site documentation and adding Dojo to the mix. Andy’s tutorial shows you how to build a simple application using only HTML, CSS, and javascript to allow a custom mobile application to transition from a native app to a web based application. It demonstrates not only a seamless transition but the ability to access native device functions with one common api. Read more here… [Writing a Hybrid Mobile Application with PhoneGap and the Dojo Toolkit [June 28, 2011]]

Az utóbbi cikket kísérte egy az abban foglaltakat “megerősítő” július 26-i előadás, melynek slide-jai innen tölthetők le. Ebből érdemes ide másolni a következőket, mivel lényegében erről beszél Dingsor a videóban, és igen jól megvilágítják a hibrid filozófia architektúra kiterjesztési lehetőségeit is (pl. a lenn szereplő “partition content” rész):

Two extremes for implementing mobile apps

  • At one extreme: Pure native apps
    Pros:
    • Easy to find
    • Easy to start
    • Look like a native apps
    Cons:
    • Hard to update
    • Content may be reviewed/stalled/rejected by app store
    • Platform-specific programming model, must be duplicated
  • At opposite extreme: Pure server-based apps
    Pros:
    • Easy to update (all content on server)
    • Can look native (mobile styling)
    • Familiar web languages (HTML/JS/CSS)
    Cons:
    • Hard to find (browser)
    • Hard to start (remember and type a URL)

Introducing Hybrid Apps
– Middle ground
– Best features of both extremes

  • Partition content:
    – One portion installed on mobile device
    – Remaining portion delivered from server
  • Use web technologies in mobile device
    – index.html as entry point
    – Familiar HTML/JS/CSS
  • User starts native app
    – Easy to find, easy to start
  • Seamless transition from mobile portion to server-based portion
    – Both sides styled the same
  • Minimizes frequency of native updates
    – Install stable content on mobile (eg, splash logo)
    – Deliver majority of content from server (eg, weather forecast)
  • Plus: Common javascript API to access native hardware features

Az IBM hibrid filozófiáját és PhoneGap melletti döntését megalapozta mindaz, amit ebben a cikkben találunk:

Comment lines: Mobile apps and the Web [Roland Barcia, Senior Technical Staff Member, IBM, March 30, 2011]

folytatását pedig ebben a blogbejegyzésben:

Using the Web 2.0 and Mobile Feature Pack with PhoneGap [Roland Barcia, June 24, 2011]

Konkrét fejlesztési példaként pedig egy IBM developerWorks sorozat is megjelenőben van. Ennek első része:

Mobile application development, Part 1: PhoneGap and Dojo Mobile on Android [Sept 13, 2011]

Bryce Curtis (bcurtis@us.ibm.com), Mobile and Emerging Technologies, IBM

Gill Woodcock (gill_spencer@uk.ibm.com), Software Services Consultant, IBM

Todd Kaplinger (todkap@us.ibm.com), Senior Software Enginer, IBM

Summary: In this series, you’ll start out by creating a simple, mobile application, and end by consuming web services from your Android device. Learn how to use Eclipse and PhoneGap to create a mobile hybrid application using only HTML and JavaScript. You’ll also use Mobile Dojo to give the application that native feel. In this article, learn how to combine PhoneGap and Mobile Dojo to rapidly create a hybrid mobile application for Android that looks and behaves like a typical Android application.

View more content in this series

Tags for this article: android, bryce_curtis, dojo, gill_woodcock, html, javascript, mobile_app, mobile_web, phonegap, todd_kaplinger

25 hozzászólás

Subscribe to comments with RSS.

  1. Nagyon jó dolog. a WebGUI is ebbe az irányba megy. Sokan látnak benne fantáziát, pl. a WEBGUI-ba igen komoly pénzt fektetett be a Citrix, pedig ő nem igazán a fejlesztésekből él meg, de gondolom látták a technológiában a fantáziát az ő fő tevékenységi területeiken is.
    Én el tudok képzelni egy olyan fejlesztést (sok ilyen többé kévésbe kiforrott, működő próbálkozás van) mikor az alkalmazás meg van írva desktop technológiára majd kicserélve alatt a desktop UI rendszer könyvtárakat WEB böngészőn belül futó alkalmazássá válik. Ezen úton sok buktató van de ha jól particionálják a fejlesztési erőfeszítéseket a kliens és szerveroldali feladatokat akkor igen jól működő megoldás sikerülhet belőle, ami igai multiplatform ha a rendering oldal jól ki van találva. Jövőre mikor megjelenik a mobil presentation layer a NETHTML5-höz, akkor ez már igazi multiplatform lesz.

    Dobi Sándor

    2011. október 5. szerda at 16:42

  2. […] FOLYTATÁS ITT Elküldve 2011. 10. 06. 23:36 by Nacsa Sándor Megtekintve: 0 alkalommal Támogatóink | Kapcsolat | Tagok | Adatvédelmi nyilatkozat | Felhasználási feltételek | 2011, DevPortal // // //> //> $(document).ready(function () { $('ul.sf-menu').superfish(); }); […]

  3. […] Valóban? ], HTML5 Windows Phone Mangora és [az én október 5-i tényfeltáró elemzésem: PhoneGap-el abszolút leghatékonyabb?] A Windows 8 alkalmazás modellje. [Szept. 28: végre megkezdődött a konferencia […]

  4. […] […]

    Névtelen

    2011. október 7. péntek at 13:49

  5. Kedves Sándor!

    Nem találtam más módot a kapcsolatfelvételre, ezért ide írom a kritikám: nem nagyon szeretem olvasni az ön által szerkesztett blogokat, mert úgy gondolom, hogy a tördelés és a tipográfia meglehetősen szerencsétlen. Természetesen ez a kijelentés mit sem ér konstruktivitás nélkül:

    – célszerű lenne a hosszabb írásait fejezetekre bontani, valamint megoldani a fejezetek közti navigációt egy tartalomjegyzékkel, mert ez az egybefüggő szöveg elsőre (és másodszorra) elég ijesztő
    – túl sok a kiemelés, így nehéz eldönteni, hogy mi valójában fontos; először csak pár szó félkövér, aztán egy egész bekezdés, aztán ezt azzal fokozza, hogy az egész félkövér bekezdést pirossal írja, végül ad neki egy sárga hátteret; ez így nem jó, elvonja a figyelmet, ráadásul nem biztos, hogy mindenki azt tartja érdekesnek, amit ön
    – összességében az írásai inkább keltik egy vidéki kisváros helyi újságjának érzetét, amit szabadidejében az általános iskola fizika/számítástechnika szakos tanárja szerkeszt, mint egy professzionális, hasznos információkkal teli, gondolatébresztő és -rendszerező “kiadványét”, aminek szerintem ön szánja, és ami lehetne.

    Tisztelettel:
    Hidvégi Gábor

    Hidvégi Gábor

    2011. október 9. vasárnap at 17:57

    • Kedves Gábor!

      Az olvasók többsége valószínűleg hasonlóképpen vélekedik, és én ezt — furcsának tűnhet — teljesen megértem. Hogy akkor miért ilyenek mégis ezek a blogbejegyzések?

      Leginkább ilyen az Experiencing the Cloud, ami eleve nem hazai fogyasztásra készült, sőt itt az olvasók általi fogyasztás csak sokadik szempont volt. Mint ez a főoldal első mondában szerepel, ez egy:

      trend tracking website

      amivel az általam a:

      fueled by 3.5G/3.9G, SoC & reflectivity

      trendmeghatározónak vélt keretek közötti történéseket dokumentálom folyamatosan. Itt eleve az adott történésre vonatkozó információk rendezett formában való kigyűjtése volt a meghatározó szempont, és az ebből esetleg adódó igen nagy bejegyzés méretet kellett, magam számára mindenképpen, azzal ellensúlyozni, hogy a későbbi gyorsolvasást (saját gyorsolvasásomat) a WordPress lehetőségei melletti kiemelésekkel segítsem, támogassam.

      Másik végletet képvisel a KultúrKúra, mely a:

      Komplex művészeti terápia jegyzetek

      jegyében született, egy évvel ezelőtt, feleségem ilyen irányú tanulmányainak segítésére (ami december 11. után felfüggesztésre került, így maga a blog is). Ez kifejezetten törekedett az olvasók kiszolgálására, aminek eredményességét talán jól jól mutatja, hogy a messze legolvasottabb, A lila szín és fő kiegészítő árnyalatainak (bíbor, ibolyakék, orgonalila, mályva, bordó) jelentése és szimbolikája (webes áttekintő tanulmány) a mai napig igen népszerű olvasmány, sőt olvasása azután vette kezdetét, hogy abbamaradt újabb bejegyzések közlése:
      KulturKúra A lila szín és ... című bejegyzés egy éves statisztikája -- 2011. október 10.
      Számomra ez azért is érdekes, mert amibe igen sok “olvasó vonzó” megjelenési, szöveg és kép munkát beleöltem, a Pompidou Központ, te ellentmondásos “csak” 198-as nézettséget ért el, pedig ezt is olvassák a mai napig.

      Összes többi blogom (Szoftver aktualitások, HTML5+svg[2]+css3+ecmascript5+domL2/L3 és Beyond Win32) valahol e két véglet között foglal helyet (különböző okokból). Ahol az említett olvasási problémák erősebben fordulnak elő, ott csak ezzel fordított arányban kevesebb időt tudtam az olvashatóságra fordítani (egyszerűen nem volt több időm magához a témafeltáráshoz, körbejáráshoz, értelmezéshez … stb. képest, az utóbbiak terén a lehető legnagyobb alaposságra és körültekintésre való törekvés miatt). Ezért minden olvasóm elnézését kérem, de egyben remélem, hogy megértik erőfeszítéseim értelemszerűen korlátozott jellegét és elfogadják az ezzel náluk jelentkező többlet erőfeszítést. Úgy gondolom, hogy sokan rájöttek már az adott témák ilyen “olvashatósági (és nem érdemi, szakmai) feldolgozottság” melletti tájékoztatási előnyeire a saját jól felfogott üzleti vagy más érdekeik szempontjából véve. Erről árulkodnak nekem a blogok igen magas olvasottsági statisztikái.

      A Szoftver aktualitások – statisztika február 8. és október 10. között:
      Szoftver aktualitások – statisztika február 8. és október 10. között
      A HTML5+svg[2]+css3+ecmascript5+domL2/L3 statisztika 2011. március 25. és október 10. között:
      HTML5+svg[2]+css3+ecmascript5+domL2-L3 – statisztikák 2011. március 25. és október 10. között
      A legkevésbé sem más olvasók megnyerésére szánt Experiencing the Cloud esetében pedig (igaz itt az angol nyelv miatt nagyságrendekkel nagyobb az a tábor, amiből kikerül a “még ilyen formában is megéri” olvasók köre) ez a 2010. június 23. és 2011. október 10 közötti statisztika:
      Experiencing the Cloud statisztikák 2010. június 23. és 2011. október 10 között
      (A Beyond Win32 statisztikát azért nem említem, mert azt migrálnom kellett március végén a WordPress-re, és majd csak akkor kezdem újra, amint a Windows 8 publikus bétában lesz, mivel akkorra már a Microsoft is eldönt egy csomó dolgot és ehhez elegendő forrásinformációt kínál. Addig megteszi nekem a Szoftver aktualitások ez ügyben is. Mint ahogyan eddig is megtette.)

      Megjegyzem éppen szombaton, a Magyarországi Web Konferencián közölte velem egy jóval korábban ilyen jelleggel igencsak kritikus, és egyébként rendkívül magas szakmai színvonalon dolgozó fejlesztő, hogy olvassa ám blogbejegyzéseimet (közölte magától) és éppen arra hivatkozott, hogy milyen hasznos számára az alkalmazott kiemelés, mert ezzel roppant gyorsan átlátja a közlendők lényegét és dönteni tud a további részletek tekintetében (melyik részt olvassa, abból mely linkek mentén menjen tovább stb.). No hát ilyen is van.

      Ami ezek után a kritikai észrevételekből marad (fejezetekre bontás, tartalomjegyzék) azt elvben meg lehetett volna valósítani, ha menet közben rátaláltam volna az ennek megfelelő wordpress.com-os lehetőségekre. Kerestem, de sok időm nem volt erre. Még a wikipedia-hoz hasonló megoldást sem találtam, pedig nem tudom elképzelni, hogy ne lenne a wordpress.com-hoz (ha más nem, akkor plug-in formájában). Ezért nagyon megköszönném, ha tudna ajánlani nekem ilyet az olvasótábor. Gábor vagy másvalaki.

      Ezúton külön köszönöm Gábor hozzászólását, azért is mert erre az udvarias és saját név feltüntetésével érkezett kritikára feltétlenül illendő, érdemi válaszom remélhetőleg világossá tette, hogy nem saját “írói, szerkesztői” képességeim korlátai teszik ilyenné a blogokat, hanem a meglehetősen sok és sokfajta ügy mély képviseletéhez rendelkezésre álló szűkös kapacitás.

      Innen is kérném az olvasók ez irányú megértését. Egyben ígérem, hogy amennyit kevés befektetéssel javítani tudok az eddigieken azt meg fogom tenni.

      Üdvözlettel
      Nacsa Sándor

      nacsa

      2011. október 10. hétfő at 11:07

  6. Gondoltam ide írok a devportal helyett, mert ott nem nagy az érdeklődés a témával kapcsolatban, illetve egy idő múlva eltűnnek a figyelemből a hírek…

    Szóval elsőre megtetszett a phonegap. Először 1-2 órát foglalkoztam vele, próbálgattam, működött tetszett🙂
    Aztán elkezdtem gondolkozni, hogy is működik. Utólag a fenti cikk nagy részét átolvastam, és abból is kiderült, de nekem sem esett sok időmbe rájönni, hogy igazából hogy is működik a phonegap (legalábbis androidon):

    Annyit csináltak “csak”, hogy minden platformra fordítanak egy natív alkalmazást, ami kb arról szól, hogy van egy beágyazott böngésző kontrol (WebView) az alkalmazásban.

    Kb ma 1,5 alatt megcsináltam azt, hogy androidon (nem phonegap-al), csináltam egy mezei androidos projektet, kiraktam fullscreenre, ráraktam egy webview-t, betöltöttem a lokális index.html-em az asset könyvtárból, meghívtam javascriptből egy java-s függvényt, onnan visszahívtam egy javascriptes függvényt.
    Működik.🙂

    Gondolom más platformon sem bonyolultabb a megvalósítás.

    Innentől kezdve számomra az a kérdés, hogy milyen előnye származik bárkinek a phonegap használatából?
    Egyedül csak az elkészített api hívások megvalósítása (javascript wrapper metódusokon keresztül) az, ami valamennyi értéket ad hozzá.

    Ugye azért azt lássuk be, hogy általában natív hívásokra nem lesz szükség, de amúgy sem egetrengetően nehéz egy-egy api gyors javascriptesítése.

    Viszont ha használjuk a phonegap-et, akkor cserébe fizethetünk a commercial használatáért…
    https://build.phonegap.com/

    Mivel nincs a phonegap-hez globálisan használható fejl. környezete, illetve ha nincs a cégnek dreamweavere, akkor így is-úgy is el kell játszania mobil platformonként egy-egy fejl. környezet felrakását, üres projekt létrehozását, referencia phonegap-os libraryra (jar), javascriptre, stb , ami nem sokkal több idő, mint amit leírtam feljebb🙂

    Ahol van egy dedikált fejlesztő a témára, szerintem pár nap alatt sok-sok kávé/cigi szünettel végigveri szebben a szükséges 3-4 platformon azt, amit én androidon 1,5 óra alatt elértem, és már mehet is a html5 + javascript + css combo-s multiplatformos fejlesztés, bármilyen kötöttség nélkül!🙂

    YellowCat

    2011. október 20. csütörtök at 00:16

    • Re:

      Milyen előnye származik bárkinek a phonegap használatából?
      Egyedül csak az elkészített api hívások megvalósítása (javascript wrapper metódusokon keresztül) az, ami valamennyi értéket ad hozzá.

      Ha megnézed a PhoneGap 1.1.0 API Reference [Oct 1, 2011]-et rögtön látni fogod, hogy az API hívások megvalósításához képest milyen minőségi többletet kapsz. Ha neked magadnak kellene például “kikurkászni” a különböző natív platformok tulajdonságait (milyen device-t támogat, milyen értelemben … stb.), továbbá valamiféle közös nevezőre hozni azt, máris nem néhány nap, hanem — a mai platform, azon belül device API diverzitást figyelembe véve — máris több emberévnyi fejlesztői időigényhez jutsz. Ezt ráadásul még egy IBM sem engedheti meg magának. Egyébként, ha belevágnál, akkor abba is gondolj bele, hogy amíg te dolgozol, addig mennyire tovább fokozódik a platform diverzitás. Egyszerűen sosem fogod utolérni magadat.

      Mindemellett az sem elhanyagolható szempont, hogy a PhoneGap API-k industry standard-nek tekinthetők ma már, tehát minden JavaScript fejlesztő ugyanazt használhatja (szemben a te saját API-ddal). … stb.

      Ha ez túl általános számodra, akkor gondolkozz el azon, hogy a PhoneGap 1.1.0 API Reference [Oct 1, 2011]-ben rendre megtalálható “XXXX Quirks”-ek milyen többletértéket képviselnek az általad “feltárt” API implementációhoz képest. És ez csak egyetlen példa (bár a leglátványosabb és a legkönnyebben érthető).

      Üdv
      Sándor

      nacsa

      2011. október 21. péntek at 14:37

      • Az API-val kapcsolatban teljesen igazad van, és üzleti alkalmazásnál valószínűleg használnám is (utólag vettem észre, hogy storage alatt ott figyel a saját sql implementációjuk azon böngészők alá, amelyek nem támogatják a w3c-s websql-t), viszont most pont egy egyszerű kis hobbi projektet csinálgatok szabadidőmben, és kvázi fél óra alatt nem sikerült elérnem azt, hogy a phonegap-os android verzió (widget?) teljes képernyőn fusson, title nélkül.

        Találtam 3-4 példát, hogy kell android alatt fullscreenre kirakni az alkalmazás felületét, de csak akkor működik, ha standard android appot csinálok. (Ezért kezdtem el nézegetni alternatív lehetőséget).
        Szóval azért kicsit bennem van a félelem, hogy megkötésekkel is jár egy 3rd partys eszköz. (már sokszor tapasztaltam), természetesen sok az előnye, de már belefutottam nem egyszer abba, hogy más egyéb apróságra több idő ment el, mint amit nyertem az adott komponenssel!

        Mindenesetre futok még pár kört a phonegap-el!

        YellowCat

        2011. október 21. péntek at 16:16

      • Kiváncsian várom az eredményt.

        nacsa

        2011. október 21. péntek at 18:06

  7. Eddig annyira volt időm, hogy a lev. listára írtam 2x-er, de senki sem válaszolt a kérdésemre, cserébe ömlesztve jön kismillió levelezés onnan, jó lenne valamilyen normális fórum…
    Esetleg van nekik, csak én nem találtam meg?

    YellowCat

    2011. október 24. hétfő at 16:13

  8. A Google Groups-szal próbálkoztál?

    nacsa

    2011. október 24. hétfő at 19:00

    • Igen

      YellowCat

      2011. október 24. hétfő at 21:45

  9. Emellett vannak fizetős támogatások: http://www.phonegap.com/support#support-packages

    nacsa

    2011. október 24. hétfő at 19:14

    • Tudom, de egyelőre csak tesztelgetem, azért elég egyszerű a probléma, csak választ nem nagyon kapok rá…
      Ha sok időm lesz, valószínűleg átnézem, hogy is épül fel a DroidGap ősosztály, hátha egyszerű a megoldás

      YellowCat

      2011. október 24. hétfő at 21:47

  10. Sok időm nem volt foglalkozni mostanában a phonegap-al, de a kezdeti félelmem/gyanúm kezd beigazolódni, miszerint a különböző mobil böngészők között is elkezdődik a jó öreg html-js-css kompabilitási probléma.
    Pár napja vagyok a phonegap-os google groupsban, de már jött jó pár olyan mail, ami arról szól, hogy valami megy az egyik böngészőben, emulátoron, másikon nem, vagy csak az egyik stílust képviseli valamelyik framework, és nem illik a másik koncepciójába.

    Itt a legutolsó kifakadása az egyik fejlesztőnek:

    “I have been framework shopping for what seems like forever now.

    tl;dr version: All the existing frameworks suck.

    All of them have good and bad bits, none of them totally meet my needs.

    One of my biggest complaints about the current frameworks is how iOS-centric they all are. Even when a framework purports to support Android (some even claim to have a theme for Android) they still use navigation concepts that are iOS-centric. I *want* to like Sencha Touch and jQuery Mobile etc etc etc… but I don’t.

    I have even started writing my own (at least for when I am doing an app for Android). We’ll see if I ever get it mature enough that I am game to use it…

    It’s only attempting to do Android-looking tabs (on the top), table-views, etc… using iScroll4 for scrolling… jQuery for DOM manipulation… etc etc.

    Still trying to get CSS transitions to work properly with my back button implementation… *sigh*

    Maybe after this I will know enough to at least hack one of the better existing ones (like jQTouch) to suit me better…”

    Amúgy most egyre többen akarják megváltani a html-mobil világot, a legközelebbi framework talán a kendo ui lesz, novemberben jön az első verziója, és hirdeti az oldalán, hogy a phonegappal együtt teljesértékű natív alkalmazást lehet készíteni vele : http://www.kendoui.com/kendo-ui-mobile.aspx

    Illetve a fenti problémára is megoldást nyújt majd (elvileg):

    “On iOS, Kendo UI Mobile widgets look native to iOS. On Android, Kendo UI Mobile widgets look native to Android. Automatically. Kendo UI Mobile detects the device and applies the proper styling.”

    YellowCat

    2011. október 26. szerda at 08:46

  11. […] JavaScript reneszánsz? Valóban? és PhoneGap: avagy a mobil fejlesztés leghatékonyabb HTML5/JavaScript-ben? című írásaim még ennél is messzebbre mutató következtetésekre […]

  12. […] részletes és mindenre kiterjedő információ: – PhoneGap: avagy a mobil fejlesztés leghatékonyabb HTML5/JavaScript-ben? (Nacsa Sándor, 2011. október 5.) – Implementing WebStorage for PhoneGap + Windows Phone Mango ( […]

  13. […] 7-én kiadták a PhoneGap újabb verzióját (letöltés). A legnagyobb változás, […]

  14. Gondoltam kiprobalom a Phonegap-t, de sajnos mar a telepitesnel elakadok, Lion alatt Xcode4-el szeretnem kiprobalni, ha elinditom a PhoneGap-1.3.0.dgm-t ahol azt kell kivalasztani hova installalja azt atugorja, a legvegen pedig kiirja, hogy az install nem sikerult probaljam ujra.
    Tudja valaki a megoldast?
    Elore is koszi

    Ryke

    2012. január 16. hétfő at 09:46

  15. […] – Apache Cordova webhely – PhoneGap 1.5 Released! [March 9, 2012] – PhoneGap: avagy a mobil fejlesztés leghatékonyabb HTML5/JavaScript-ben? (Nacsa Sándor, 2011. október 5.) – PhoneGap 1.2 (2011. november 16.) – PhoneGap for Windows […]

  16. Remek a cikk!
    Általános felhasználásra jó megoldás lehet. Mi a helyzet a 3D intenzív felhasználásokkal? Annak web-oldali megközelítése még desktop-on se egységes (svg, webgl, …). Ha gyors, sok polygon-os 3d-re van szükség (játék, 3d vizualizálás,…) shader-ekkel platform függetlenül – jelenleg ez igen nagy gond, hisz iPhone / Android esetén még megoldható egy natív c/c++ 3D engine használata de WP-nál már nem (jelenleg) – rendgeteg fejlesztőnek ez okozza a problémát. Számos program ezért nem tud WP-re megjelenni. Ebben az esetben inkább az UI-t kelljen külön implementálni de az alap engine lehessen azonos.
    Ez pont a közös UI-ra ad megoldást.
    Amilyen hardver van a mai telefonokban es amilyen irányba fejlődnek, számomra ez a fő probléma.

    HunDeveloper

    2012. március 22. csütörtök at 17:34

    • Minden olyan téren, ami nem az ún. device API-k körébe tartozik a JavaScript framework-ök körében kell kell keresni azt a platform függetlenséget, amit device API-k esetében már most igen jól kínál a PhoneGap (illetve Cordova). Ez még valószinűleg 1-2 évig így lesz. Ld.
      Standards for Web Applications on Mobile: February 2012 — Graphics

      Mellesleg az oldalsávon az aktuális információk között megtalálni a teljes szabványosítási helyzetre vonatkozó linket. Ld.
      ÚJ VÁLTOZAT: Standards for Web Applications on Mobile — February 2012 current state and roadmap (Dominique Hazaël-Massieux, W3C)

      Megoldás egyértelműen van JavaScript framework szinten, mint azt a megfelelő keresés jól mutatja:
      https://www.google.com/search?hl=en&sugexp=frgbld&gs_nf=1&cp=35&gs_id=1l&xhr=t&q=3D+games+HTML5+JavaScript+framework&pf=p&sclient=psy-ab&oq=3D+games+HTML5+JavaScript+framework&aq=&aqi=&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&ion=1&biw=1680&bih=935

      Nacsa Sándor

      2012. március 22. csütörtök at 18:48

      • Köszönöm a választ!
        Igen, látom, hogy nagy a mozgolódás. Sokak érdeke lenne egy közös megoldás. Bár úgy gondolom, hogy minden általánosított megoldás csak ideig-óráig tud fennmaradni. Azaz most, hogy nagyon közelednek a mobil platformok egymáshoz + a desktop-hoz, megvalósítható közös felület – egészen addig amíg nem jön valami egészen új – ismét.
        Úgy látom, hogy 3D oldali egységesítéshez alap feltétel lenne a WebGL teljes, általános támogatása – erre most még nyilatkozatok sincsenek pl. MS (IE) ill. Apple (Mobile safari) oldalon. IE-hez is készül plugin de az azért nem ugyanaz. Ráadásul ez a teljesítmény még mindig elmarad a szükségestől.
        A nem natív alkalmazások térnyerése amúgy is nehéz helyzetbe hozhatja az összes jatékost akiknek jelentős támasz egy saját maguk által felügyelt alkalmazásbolt. Persze ez a jelen üzlete – ami még 10 évvel ezelőtt is fikciónak tűnt (sajnos MS se hitt benne eléggé pedig minden eszköze meglett volna hozzá) -, nem tudhatjuk, hogy mit hoz a jövő…🙂

        HunDeveloper

        2012. március 23. péntek at 10:35

  17. […] jómagam egy PhoneGap: avagy a mobil fejlesztés leghatékonyabb HTML5/JavaScript-ben? [HTML5+svg[2]+css3+ecmascript5+domL2/L3 blog, 2011. október 5.] bejegyzés formájában igen […]


Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: