Skip to main content

Building Blocks of My First Native App





A few months back when I was at the NASSCOM Tech-Unique (yes the second version of the It-NIketan where I had to deliver a speech last time) it seemed the event mostly centered about how Mobile Web is emerging and how we should embrace it.
In the discussion there we several interesting points raised and people started dragging PhoneGap in. While this was a very interesting topic, it disturbed me for certain reasons.


I raised my worries, and unfortunately the speakers or the panel couldn't come to any solutions. So I am still at a loss for the cons of this method.
Nevertheless I decided to put my mind out on the matter.


I consider myself well-versed in web development, and I was excited about the features that PhoneGap brings to web apps. Going the HTML5 web app route seemed like the most sane route.


Pros
  • You don't have to learn any new languages if you're already a decent web developer
  • It's very quick to prototype
  • Though we didn't end up using it, jQuery mobile is pretty neato and makes it even faster prototype
  • Lots of library options for pretty much everything you could possibly want
  • It's really cool and fun
  • If you so wanted to, you can bypass the app store by hosting the files on a server, and utilize app cache to make things speedy. Changing your app is just changing a web page and its cache manifest file
  • Managing images for multiple devices is a lot easier with CSS and media queries than it is for an iOS xcode project and an Android project with its ldpi, hdpi, xdpi, and whatever dpi.
  • Easier to create vector graphics to design spec
  • Hell, it's just easier to get things to be exactly like the design (except if you care about cross-browser compatibility)

Cons
  • There are a lot of mobile browsers out there (the state of browsers is worse than its ever been in terms of how many different crappy ones we have to support - it used to be just one, but guess how many people are on android 2.x and wp)
  • There are a lot of mobile devices out there with varying hardware, screen sizes, and network speed
  • Some features you're used to using aren't there for all devices (position: static for instance) and since those are likely the crappy devices, using a javascript shim (like iScroll) is out of the question if you care about performance
  • There seems to be some version issues with the facebook-connect plugin for phonegap (cordova) and the latest versions of phonegap on iOS only - To get facebook connect and PhoneGap to work I had to use an older version of PhoneGap
  • Documentation for PhoneGap itself is pretty decent, but it's still new, so not a whole lot of people have reliable information on current versions (at least this was the case 5-6 months ago)
  • Since I had to use an older version of PhoneGap, I found that some of their api functions would cause javascript errors. I had to bypass the sugar they provide and call PhoneGap.exec directly on their com.phonegap.whateverFunctionality - It was ugly, but it worked
  • There are complications with linking to other apps like Google maps
  • I found that saving contacts did not work on all versions of iOS
  • jQuery Mobile + Backbone is more of a pain in the ass than you think
  • Getting neato transitions can be a pain
  • There are less facilities in javascript for modularization of large-scale applications than Objective-C or Java

If your app is simple, then I recommend it. I really did enjoy the process and seeing my web app as an installed app. But, just know that it is more trouble than it appears to be

Comments

Post a Comment

Popular posts from this blog

Racecraft (Project Koru) · Prologue — The Origin Story

Racecraft · Prologue , The Origin Story It Started With a Wine List and a Question About Racing How a happy-hour conversation in the Bay Area turned into a trustable AI race coach , and then into a second version that runs entirely on a phone, on the NPU. This is the prologue to a five-part series. Two years ago(1st November, 2024) I was in the Bay Area for a GDE Summit. If you've never been: it's a couple of days of talks among Google Developer Experts, the kind of people who get unreasonably excited about a new on-device runtime, and then , mercifully , a happy hour where everyone stops performing and just eats. We ended up at a restaurant(Puesto Santa Clara), a long table of GDEs, and I was doing the most important engineering of the evening: trying to decide which wine to order. Across the table was Ajeet Mirwani . I don't even remember how the wine talk turned into racing talk , these things drift , but the moment the word "racing" ...
Post a Comment
Read more

The Throughput Trap: Benchmarking vLLM on OpenXLA and the Reality of Production LLM Serving

vLLM Systems · DevLab 2026, Deep Dive I was recently invited by the Google TPU team to speak at the OpenXLA Summer DevLab 2026 . This post breaks down our deep-dive evaluation of the matured vLLM + OpenXLA stack, the fundamental engineering mismatches between CUDA and XLA serving paths, and why traditional capacity metrics are lying to you. If you are operating large language models at enterprise scale right now, your platform architecture team is likely staring at a massive infrastructure crossroads: Should we migrate our core serving workloads from GPUs to TPUs? Historically, NVIDIA's CUDA ecosystem was the only serious option for user-facing, low-latency LLM generation. But here in 2026, the economics and infrastructure options have transformed. Google TPUs are highly available, cheaper per chip, and the open-source serving stack built around vLLM and OpenXLA has officially achieved absolute production readiness. Yet, when our infrast...
Post a Comment
Read more

A Split‑Brain Neuro‑Symbolic Training Method for High‑Velocity Autonomous Coaching from Telemetry

 Author: Rabimba Karanjai Scope: Problem statement + data methodology + model training (no deployment discussion) Abstract Real‑time coaching in motorsport is a safety‑critical learning problem : a system must map noisy, high‑frequency telemetry to short, actionable guidance that remains physically consistent and avoids hazardous recommendations . This paper proposes a “Split‑Brain” training formulation that separates (i) a semantic coaching target (what action/critique should be expressed) from (ii) a reflexive interface (how actions are represented as compact, verifiable tokens). The approach trains a Small Language Model (SLM) in the Gemma family [1] using QLoRA fine‑tuning [2] , and introduces a telemetry tokenizer plus teacher‑student synthesis pipeline to generate instruction‑action pairs at scale. Core contribution: a reproducible method to convert “ golden lap ” differential tel...
Post a Comment
Read more