dozy

Plenty of use cases...heres one: I've been loving my 360 for exercise. Not only for the step counting (and the Asus Wear watch has GPS I believe).

I've always taken issue with carrying a phone around with me while running. With the 360 (and the latest update), you can pair with bluetooth headphones and play music that you've synced from your phone. And obviously since it's a watch, I can time myself. I can then sync my interval timing results, etc.

Regarding your request for a high-level overview...it's an extension of the Android platform designed specifically for wearables, is it really that hard to see the potential? Take what you know about Android and what it can do, and Wear is that + APIs for tiny UIs + an sync-focused abstraction layer on top of bluetooth pairing. Additionally, consider not only that the screen is tiny, but the HCI ramifications/opportunities given that it's on your wrist, or ankle, or whatever. AFAIK, you can build a Wear device with any hardware you want. The models we're seeing right now are leaving out things like GPS and LTE radios for obvious cost and battery life concerns. When I think about what Wear could do, that's the context I consider.

Sure, testflight makes it easier (it's been around for years...). But you still have to invite people to testflight, after theyve signed up and added their device, you can provision the app for each device, after adding it to your developer account. Finally you can upload the build and have people install it. Obviously the process gets easier with time, and if you're not adding new people to the team.

But, with Android you build the APK and send out as an email attachment to whoever and you're done. Set up a shared directory on dropbox or google drive or w/e if you want.

Full disclosure: I'm biased as I'm primarily an Android engineer. But, I've led teams and developed extensively for both platforms, so I'll tell you a couple things I've observed.

1. If you already own an iOS or Android as your primary device, that should play big into your decision. You'll have a much easier time maintaining interest in your project as well as being more likely to create a more compelling product if you live on the platform.

2. Google's Android documentation and guides are on a completely different level than Apple's for iOS - Google's is just so much more extensive. It's really not even close IMHO. If you're a beginner I think this will make a very large difference.

3. The iOS developer program and provisioning system is a PITA, even for experienced developers. Often times when learning something new, all it takes is a small roadblock to become frustrated and lose interest. With Android, building apps for you and your friend's devices is very easy, and submitting to Google Play is much easier, with no review process and again just one guy's opinion, but despite a recent (and dearly needed) makeover, iTunes Connect is still inferior w.r.t usability compared to the Android Developer console.

4. I used Eclipse + the ADT plugin for years and while it wasn't terrible (I was come from J2ME development for BlackBerry so the bar was quite low), I was always jealous of Xcode. Google has now addressed this with Android Studio. It's still a bit of a moving target, but I now consider on par or better than Xcode.

5. Don't let the haters scare you away with the fragmentation arguments. "Fragmentation" is a feature :) Truthfully, if this is just a side project, I would set a minSdk for your app a minimum 14, or even 19 if you want to, and be amazed by how your app works so well on the 100s or 1000s of devices out there that it supports.

Couple words on iOS:

1. Whereas with the x86 emulator and Genymotion, the Android emulator has dramatically improved, the iOS simulator is still superior with respect to ease of use and pace of development.

2. If you go the iOS route, I would strongly suggest to go directly to Swift. It's where the puck is going and you've got a chance at this point to be a relative expert among a sea of objective-c developers, who will need to learn it as Apple increasingly shifts the platform.

3. This is very subjective and nebulous, but after using both platforms extensively, I've found the iOS APIs are simply better. You'll find things just work and you'll be continually surprised to find the puzzle pieces just fitting together. (ie "hey I wonder if there's a way I do X...oh perfect there's just a simple method call for it")

4. As others have noted, if you don't have a Mac then the point is moot, Android is your only option.

Hope this helps!

This is important news for iOS developers as it means they must build and test their app on iOS 8, including any libraries that they use.

There are many ways and reasons why changing your build target may affect your app, so much so that's it's far beyond the scope of a hackernews thread. Supporting 64-bit, although introduced a while ago already with with iPhone 5S, can present some tricky bugs, also too much to explain here.

It's also meta-interesting as it shows the pace at which Apple wants app developers to adopt the new APIs, and will ultimately result in a more modern/ios 8 friendly app landscape.

EDIT: somebody else noted that you can likely still target earlier versions, which on the whole makes this much less interesting.

No - it just means new iOS apps must support 64-bit and be built with Xcode 6. Those same binaries/archives can also support 32-bit and older OS versions.

Similarly, today, you must build your app using at least the iOS 7 SDK and xcode 5, but that does not prevent you from supporting iOS 6 as well.

Actually it seems it's a different camera than the 2014 Moto X, my evidence being primarily the larger aperture size, also OIS.

OP here - if anybody has any questions for how mParticle works (vs. Segment.io for example), happy to have a discussion here!

Ah, interesting way to qualitatively determine diversity. Taking the quoted example, from my perspective a city with 100 ethnic groups, each with 1%, is much more diverse than the example with 4, each with 25% - but they share the same entropy index of 1. Do I have that right?

I'm curious as to your source or why you say, in no uncertain terms, that Houston is "the most diverse in the country". If such a thing could be accurately quantified, I would bet my life savings on NYC.

The quote is from the perspective of 'a woman from Beijing', it's not meant to be an exhaustive list, just as this article is not meant to be a research study - it's a perspective piece. Interestingly enough, it implies that women from Beijing (or at the very least this one) are under the impression that those are the only three jobs available to Chinese immigrants. Of course there are more possible jobs available, but I find the anecdotal perspective more valuable in this journalistic context.

I once worked for Pyxis Mobile (now Verivo Inc.) which touted a platform which would provide you with native iOS, Android, and BlackBerry (years ago..) apps, which would build themselves at run time based on a database/app meta data. This allowed apps to completely change themselves without a resubmission, while being in-line with Apple's guidelines, and technically be purely native. Between lazy loading and the fact that the interfaces were simple, the system worked well. Point being - I've thought a lot about and seen the result of the "avoid app store submission" value proposition.

After all these years, I find the aforementioned value proposition...not that valuable. In my experience it's fine to only be able to push iOS updates on something like a once/week cadence. Of course on Android, you can push daily if you really want to.

Ultimately, my thought is that with all of the complications and hard work required to create and maintain a mobile app, this is a tiny piece, and should play little into your decision when choosing to develope natively vs. w/ Meteor/phonegap vs. something else. Of course, the geek in me and the Android fanboy in me loves skirting Apple's "guidelines". :)

It should be noted that the Samsung Gear Live (one of the first two Android Wear devices from last June), as well as the Moto 360 both have a heart sensor, powered by an LED on the back of the device, just as Apple's will.

I could be mistaken here but it seems BLE is not only "supported" but may indeed be a requirement of all Android Wear (aka Android API level 20) devices. AFAIK every Android Wear watch has noted an Android 4.3 requirement for the paired handset, which is also the API level (18) where BLE was introduced to Android.

Try out Genymotion, I think that's your best bet for AMD.

Hey Android developer here. I used to have the same issue - even on a fantastic machine the emulator would run very slowly, or not at all. This is now completely different

You no longer have to emulate ARM. You can run the native x86 image, using GPU acceleration, and the thing screams. I can get multiple high resolution emulators running in parallel without issue. I'm still used to debugging every single compile on an actual device having been through years of slow emulation, but let me tell you that the environment is quite different now. Genymotion is even better, but not by much with regards to performance.

To address the speed problem you could still leverage sqlite locally as cache layer in between your in-memory cache and longer-term google spreadsheet cache, and use a repeating job to move the sqlite data over to google spreadsheets (and subsequently delete those rows in the sqlite, keeping the sqlite db at a small size).

Correct. Chrome is a separate project from the AOSP.

That said, Android 4.4 and later use Chromium for their WebViews, the source for which is developed along with Chrome as a part of the Chromium project - it does not live in AOSP.

Presumably the stock browser that is in AOSP 4.4+ wraps Chromium, which more or less means the AOSP browser is Chrome...but not the other way around. :)

How does this compare to loading up a String of json in an org.json.JSONObject and parsing it manually?

For some further abstraction/encapsulation, you can extend the JSONObject class and provide getters/settings for particular key/values.

Agreed it's a shame this is read only - I'd like to build this for Android Wear, among other things.

You could build a companion app, send the HTTP request you mention, which would trigger a push notification to that user's companion app/device, which could then trigger a deep link to the Uber app :)

Regarding the article 'Let Users Explore Before They Commit' -

This is much easier said than done, and the effort and complexity will vary greatly depending on your site/app. The example used (nondescript clothing app) is one of the simpler cases, whereby the cross-session and device user-state need not be maintained, or is at least pretty minimal.

For many app developers, though, the richness of their feature-set doesn't come across until the user has a detailed state, such as level achieved, past activity, preferences, etc. Without asking users to "commit", sites/apps need to associate state with an anonymous user.

Unfortunately, it's not quite trivial to maintain the concept of an anonymous user. For one, the lengths the mobile industry is going to restrict the use of unique device identifiers poses a complexity to identify the same device across sessions. Moreover, anonymous users pose an issue for services with a value proposition behind their cross-device/platform support. Also, for small sites, it may not be trivial to introduce a data-model that supports anonymous data, which either needs to be thrown out or eventually merged with account-linked data. Similarly, 3rd-party engagement and funnel analysis of anonymous users is also a hard problem, as when the user does eventually identify themselves with an account, you need to merge their previously anonymous data into their account. Some services call this Aliasing.

I'll echo other comments that the content is sparse - this section specifically speaks as if registration count is the sole goal of the target audience. A comprehensive document would account other conversion-like goals that site/app makers might have, and the weigh the cost-benefit analysis of requiring registration.

Also can be phrased as: "Rarely used, low-level Socket class intentionally doesn't perform automatic SSL certificate verification, and is documented as such."

Wow, didn't realize. That said, it's functionality is very limted, requires an API key, requires people to subscribe to you, and likely has rate limits - none of which are problems if you just pose at the Yo app and use private APIs.

I sent a friend of mine about 2000 Yo's (Charles will show you that the Yo app uses Parse...very simple API requests) with Charles's request-replay feature - quite easy to do and oh so funny...or at least I thought so.

no problemo! I enjoyed the post - I do this kind of thing daily for my job, which just so happens to require that I "understand" how many private APIs work ;)

Yep, Charles is a great proxy. Fiddler for Windows is a great free option as well.

Warning: the author of this blog very nonchalantly instructs readers to install the Charles certificate. If readers don't know what this does, it can be quite dangerous. Next time your device connects to a Wifi network that you don't control, you could very well be going through somebody else's proxy and have all of your https traffic sniffed!

Better to sign your own certificate and use that instead! Or, at least uninstall the Charles cert from your device after you've had your fun sniffing traffic on your own network.

conceivable that the 3.5 seconds includes some overhead related to getting the thing powered up and pointed in the right direction. Also conceivable that it peaked at 50mbps for just a moment. I'll also throw in that whatever protocol they're using...I'm guessing it's not bit torrent over HTTP over TCP :)...has overhead as well to account for errors and OUTER-SPACE related nuances! anyways I'm willing to give them the benefit of the doubt.

Whoever coded the NRMP website are apparently complete rookies - they've exposed sensitive information in the HMTL source of their site. Match results are supposed to be hidden until Friday 3/21.

Update: the NRMP website has apparently been taken down.

Yeah yeah, the Android code suffers from the same lack of good OO design/code organization as the iOS code, but frankly it's such a simple sdk, it won't matter until it's feature rich and complicated. Anyways, some immediate concerns as I see it:

1. Sending requests every 10 seconds (and/or at every onPause) is no-good for battery life. Please, let the radio power down once in a while!

2. Using DefaultHttpClient with no connection pooling

3. It's doing a ton of work, allocating objects, logging events, in every onResume/onPause...I don't like this design. That includes when I get a pop-up message from another app, even if I dismiss it immediately.

4. Would be nice to register for activity lifecycle callbacks for api level >= 14, so people can't screw up the implementation.

wow, quit your bellyaching and borrow an external cd-rom. Or, buy one for $30 (or less?). I don't know how you value your time, but surely $30 is worth it for the amount of time you've spent thinking about this, writing about it, on the phone, and now responding to people about it.

also, hilarious that in my chrome, the obnoxiously massive adobe flash banner on your blog is crashing: http://snag.gy/FEVCV.jpg

The first two points of this write-up are largely invalid.

1. Mobile devs. don't know where their downloads come from

Every single large/popular ad network that I've dealt with has a conversion and download tracking system in place. A user clicks on a banner or some other media link to the App Store/Google Play, passing one of many unique identifiers (udid, device id, idfa, device finger printing). If that same user downloads and opens the app, the app makes an API call to the ad network with the same device identifier and BOOM, you've tracked a download. This is mobile marketing 101. It's a little trickier recently because of the move from UDID to IDFA on iOS, but still quite effective at tracking the acquisition process and value of mobile campaigns, and nothing has change on Android. Does she think companies are just throwing money at ad campaigns without tracking their success??

In addition to the aforementioned standard ad-network practices, Google Play and Android allow you to specify a referrer in a URL to Google Play, which is then passed to your application if it ends up getting downloaded, which the Google Analytics SDK will then pass to Google Analytics. Funny, she shows the referral section as something that isn't available on mobile - this is the exact screen that gets populated with Google Play referral data.

2. Mobile developers don't know when their apps are deleted

The Google Play developer console tells you how many uninstalls you get per day, along with how many active installs you have. It's quite useful in tracking overall trends in engagement and retention of users.

For iOS or if you want something more precise for Android, the respective push notification services (APNS and GCM) both allow (and in fact, encourage), you to use their APIs that expose exactly which push token/devices have your application installed.

If neither of the above work for your app, plenty of analytics toolkits (Google Analytics, Localytics, Flurry) are there to give you engagement data. Hell, on Android you can have your app start on boot and ping your server if you really wanted to see if it's still installed.

"Reasons far out of any developer's control"? Hardly!