New York Tech Journal
Tech news from the Big Apple

How to Build a Bulletproof #SDK

Posted on June 3rd, 2016


06/02/2016  @Yahoo, 229 West 43rd Street, NY, 10th floor

20160602_183850[1] 20160602_190336[1] 20160602_191143[1]

The speaker from @Flurry emphasized four main themes on the way to making happy developers using your SDK:

  1. Respect users (hardware, not people in this case)
  2. Respect developers (people)
  3. Clarify assumptions (more about developers)
  4. Things you can’t control

Within each theme

  1. Respect users.
    1. Be considerate of battery life. Actions include
      1. Limit network calls
      2. Illuminate the screen only when necessary
    2. Network time is expensive – keep it to a minimum by downloading once and keeping the download in memory
    3. Phone space is limited – when you are done with the data you have downloaded, delete it.
    4. Minimize startup time
      1. Use techniques to keep startup time to below 2 seconds
      2. Don’t block the main thread
      3. If possible defer loading until after startup
  2. Respect developers
    1. Don’t do anything that causes the app to be rejected from the store, such as renaming system variables in iOS or using Id’s in Android that you should not reference
      1. Don’t violate any store policies
      2. Don’t request information that is off limits
      3. Don’t call private APIs
    2. Don’t put all your good ideas in a single SDK
      1. Bloatware is not welcome (see phone space and startup time above)
      2. It’s often better to have several small SDKs
    3. Create slim SDKs and ones that don’t leak
  1. Clarify assumptions
    1. Document all your assumptions
    2. Even better, design the API’s so developers can’t violate assumptions
    3. If the SDK fails, complain LOUDly in the debug logs
  2. Things you can’t control
    1. You need to be vigilant for system changes
    2. There is nothing you can do about them, but react quickly

There are differences between #iOS and #Android that require some modifications in the SDK. One example is in the speed of the exit from an app. Apple devices tend to have less memory, so they are more aggressive in terminating apps quickly and reclaiming memory. This is less so in Android.

posted in:  Android, Apple, applications, iOS, Yahoo Tech Talks    / leave comments:   No comments yet

CodeDrivenNYC: caching web pages, #NLP, bringing #coding to the masses

Posted on November 20th, 2015


11/19/2015 @FirstMark, 100 Fifth Ave, NY

20151119_182753[1] 20151119_184814[1] 20151119_185517[1] 20151119_190304[1] 20151119_191249[1]

The first of the three presenters, David Mauro @Buzzfeed spoke about creating Mattress, their first open source IoS framework. Mattress caches web pages for later, off-line consumption. It also makes it appear that the page is loading quicker when online.

David spoke about the hurdles implementing this product

  1. How do we download an entire web page?
  2. How do we provide the content back to user

Their first decision was to download the URL using UIWebView and then capture all requests as they come through using  NSURLProtocol. UIWebView runs on main thread and is resource intensive, but the alternative to manually parse the HTML and the JS. They download the URL using UIWebView and then capture all requests as they come through using  NSURLProtocol. But WKWebView does not handle NSUIRLProtocol and there is a bug so you cannot just save another NSURLCache. They use commonCrypto to retain the URL, with the name hashed so even the longest name is uniquely identified.

They also need to know when a page if done downloaded.  Automated solutions have tendencies to either terminate prematurely or not terminate at all. Instead, they ask the user when the download is done.

How to provide the content back to NSURLProtocol? First ask the user if they are offline. If so, they retrieve the page from the custom offline cache. If they are online, the system reloads the initial request.

The system was designed as a simple API that can be run either in foreground or in background fetch. The background fetch needs to be monitored carefully so it does not use too much of the battery or slow the processing excessively.

The second speaker, Rob Spectre @Twilio demonstrated how easily applications can be made interactive using the Natural Language Processing tool, Textblob running in python.

Rob showed how to create an app that receives SMS text messages and changes its response based on your message. In just a few lines of code, Rob showed how the response can be differentiated based on the length of the message, it’s sentiment, it’s sentence structure, etc.

Ryan Bubinski @Codecademy asked the question “What is code?”

As an overview of the many ways to answer that question he recommended the 38,000 word article written by Paul Ford in Bloomberg June 2015

He summarized his view by saying that code is a lever that is becoming more powerful every day. As an example, he mentioned OpenFace, an open source program which uses a neural net for face recognition.

Making this lever available to more people requires either

  1. Making coding easier or
  2. Making it easier to learn how to code


posted in:  Code Driven NYC, iOS, Natural User Interface, Open source, Programming, UI    / leave comments:   No comments yet

#AppleWatch & #PlaceCodes

Posted on April 8th, 2015


4/8/2015 @Mission50 room 213, 50 Harrison Street, Hoboken, NJ

The presenters were

  1. Peter Kramer talking about his experience developing and app for the Apple Watch
  2. David Ingerman @PlaceCodes, tells mobile users the nearest place to purchase a product

20150408_192145 20150408_194033 20150408_195449 20150408_200549 20150408_200901

Peter Kramer talked about his experience extending his stock position app to display daily returns on the Apple Watch. His original StockPosition app monitors how your positions performed during the trading day.

He was invited to Apple’s headquarters to expand his app to display on the Apple watch. His app, “Watch My Stock” is currently being reviewed for inclusion in the App Store. The data download is still done by the phone, but the returns are communicated to the watch over a Bluetooth link. He found that the slowness of communication had a major effect on his interface design on the watch. These included:

  1. There was a delay in the download using an actual watch. This delay affected the program design. However, the simulator showed an immediate download.
  2. Since it could take 5 seconds to transmit the portfolio, the interface was designed to display the initial entries on the top of the screen as a fixed image while downloading the remaining positions which were in a more general format. These positions would be revealed only when the display was scrolled.

His description of the interface, communication link, available hardware, and programming constructions such as notifications , etc. lead me to believe that the general programming tools and hardware limitations for the Apple watch are similar to those of the Android watches. Peter was more ambitious in developing his application than I have been in my Google watch application, however, some of the issues he encountered appear to be due to quirks in Objective-C. Swift and ADT/Java may not have some of these issues.


David Ingerman @PlaceCodes: “the shortest distance between intent and purchase”, helps businesses drive consumers to physical locations. Their approach disintermediates Google by giving the seller control over the list provided to the customer of the nearby locations selling the product.

For example if a mobile user wants to buy Friendly’s ice cream, a custom web page from PlaceCode can provide nearby locations of both restaurants and supermarkets selling the product. By contrast a Google search only shows the restaurant locations and will show locations for competitors.

David talked about how their approach can include promotions. He gave an example in which customers could win football tickets when they went to a Buffalo Wild Wings restaurant on Tuesday nights. When the user opened the app on a Tuesday it would display a sweepstakes entry form if the customer was at a Buffalo Wild Wings restaurant. If it was a Tuesday, but the customer was not at a restaurant, the app would show the nearby restaurants. If it was not a Tuesday, it would show the nearby locations and invite the customer to come back on a Tuesday to enter the contest.

He talked about how the user locations where the app was opened could be mapped in real time versus the store locations. He also talked about future developments including

  1. A customer searching for locations could save a reminder/coupon to buy the product upon arriving at the store.
  2. Image recognition: a scanned billboard or other advertising image would open a list of nearly stores.

posted in:  applications, iOS, MobileDevNJ    / leave comments:   No comments yet

Building mobile apps at Yahoo

Posted on March 4th, 2015

Yahoo Tech Talks

03/04/2015 @Yahoo, 229 West 43rd St., NY

20150304_194311[1] 20150304_184758[1]

Pierre Maloka moderated presentations on #MobileApps development by six designers, developers and testers at #Yahoo. The speakers described their process from setting goals to product delivery.

The mobile development team at Yahoo was assembled two years ago and all speakers emphasized the importance of differentiating their product from those of their competitors.

Differentiation starts with a user-friendly design that emphasizes images, links to easily explore the news, and is responsive to user requests. The speakers talked about tools, organization, internal communication and testing.


  1. Keynote PDF – can extract images for manipulation
  2. Flinto – make prototypes easily for early testing
  3. Pixate – tool to build animations and interactions in native apps
  4. NodeJS and Express a web application framework
  5. Redis – data structure server to speed data from server to client
  6. Flurry – capture session, session length, active users, new users, retention, frequency of use Also use to monitor events (match to Key Performance Indicators)
  7. Slack – instant messaging which can be grouped into ad hoc channels
  8. Vidyo – video conferencing.
  9. Yo/yo link shortening. Links to documentation and dashboards.


  1. Quarterly development and review cycle
  2. Planning stage sets the goals and prototypes ideas along with initial user testing.
  3. Development stage iterates on regression and integration testing and testing by all Yahoo employees (dogfooding). It culminates in a technical and design review before being released to the public
  4. Client server tasks can be changed without re-installing the app so it contains tasks that are being evaluated or functions that will be changed frequently
  5. Tasks are broken into a presentation layer and a data layer for ease of maintenance and debugging

Internal Communications:

  1. Developers collaborate with design to figure out what to do and what is easy
  2. Get feedback as early as possible
  3. Yahoo has a pod structure so all decision makers sit together.
  4. Solicited feedback throughout all of Yahoo in the dogfood phase.


  1. Conduct testing early and often
  2. Major updates are reviewed and certified for best practices
  3. Instrument all products to monitor what users are doing

Additional comments included

  1. Most testing is manual and uses internal tools.
  2. Use Jenkins for testing on iOS. Don’t use UI testing built into XCode.
  3. Virtually all development is native on both Android and iOS, but the Android group might take advantage of web login when security is updated.
  4. The UI sticks to the format for the platform (iOS or Android). Visuals stick to the Yahoo web style.
  5. On the iOS side, they have tested Swift, but will stay an Objective-C shop for now. The main issues involve the need for more development in the IDE tooling. Also the compiled files tend to be large as Apple wants to insure backward compatible across new versions of Swift.

posted in:  Android, iOS, Yahoo Tech Talks    / leave comments:   2 comments

Beacons & Geolocation

Posted on November 7th, 2014

11/7/2014 @HelenMills space, 137 W 26th St, NY

Event sponsored by #beaconday14


Gimbal is an SDK and analytics platform for location-based mobile apps. Sessions were divided into technical walkthroughs for creating iOS apps and talks by vendors of apps using Gimbal’s services or providing infrastructure for targeting ads base on mobile location.

The two technical sessions showed how to use Xcode to construct apps with the Gimbal SDK. Geolocation apps are based on the following


  1. Location hardware which can be GPS (or other global systems) combined with finer grain services such as BTLE (blue tooth low energy) transponders.
    1. S-20 transponder which is palm size, takes regular batteries and transmits up to two years without changing batteries. Transmits Gimbal format and also beacon format
    2. S-10 (see picture) which is thumb size and works only for a few months on its battery. Transmits Gimbal format, but can be reprogrammed to transmit in beacon format.
  2. BTLE hardware to receive the signal. As of now only available on iPhone, but will be coming to Android phones with BTLE in early 2015
  3. Software: iOS Gimbal version 1 is released, but will be replaced by version 2 which is in beta. The v2 interface requires fewer software calls to the SDK. There is an Android SDK, but it is being revamped for OS 5.x which will be released in 2015. My understanding is that the current Gimbal Android SDK is primarily for use with geofence and does not work for geolocation. The software needs to smooth the inputs, create triggers for arrivals/departures, smooth the inputs for GPS and beacon, etc. The software maintains a list of beacon locations.
  4. Database software to create ad content, match to location information and determine the actions when users arrive or depart from locations.
  5. Analysis software to refine your use of the geolocation data.

Gary Damm and Sidd Panigrahi also described geofencing which is triggered by someone being within a boundary. They contrasted it with geolocation which emphasizes near location to a point in space.

Other presenters emphasized applications of geolocation.


Karen Pattani-Hanson & Megan Barry@UrbanAirship presented a case study at the US tennis Open. There 20 beacons covered the tennis center and were able to provide notifications that.

  1. Welcome first time visitor get welcome
  2. Featured activities – live streaming, US open radio, live prediction challenge
  3. Sponsorship monetization – e.g. esurance used iBeacon to identify people coming to the booth
  4. Sell last minute tickets – segment audience according to location and if on grounds, 32% click through rate

Dan Maxwell @VerveMobile talked about how Verve looks outside the store to drive traffic into the store – locate customers near the store, push inducement to go to the store, customize offers depending on location within the store. Their technology verifies that the customer entered the store and went to the part of the store. Also pops up a coupon once at that location in the store. Match to redemptions of the coupon

Antonio Tomarchio @Beintoo talked about building networks of beacons across different venues and locations and building a network of advertisers. The emphasized the importance of providing a trustworthy opt-in or opt-out mechanism

Anthony Dorment @Phigital talked about a tool that creates cards that to be displayed when triggered by a location arrival. Cards can include messages, media, video, user interaction, Google maps, etc. The goal is to make it easy to link content with the service to initiate it at a location.

Lior Nir @ShopAdvisor talked about a service across multiple vendors to alert customers to offers when they are near certain locations.

Brain Spracklen @SparkCompass talked about two case studies where geolocation data spurred user participation:

Case study #1- Ole Miss tries to encourage attendance at sports other than football. In the past needed to check in to get points. Replace by beacons. Encourage attendance once the program is announced. Also distributed to local merchants. In the future integrate with mobile payment and wearables to cut concession lines – place an order & you are sensed as you go to the concession and you are asked for your payment method.

Case study #2 – San Diego convention center – Comicon

Spark Compass will be coming out with a spark app in the next few weeks to program your own beacons and you own ads.

Toby @ControlGroup talked about some out-of the box uses for geolocation culminating in a demonstration of a companion robot – a mobile chair that can follow you (you’re your smart phone) using location sensors on the left and right arms.

posted in:  Android, applications, Geolocation, iOS    / leave comments:   No comments yet

JavaOne 2014 Recap

Posted on October 28th, 2014

New York City Java Meetup

10/28/2014 @Pivotal, 625 6th Ave, NY

Tim Fagan @Lab49


Tim summarized some of the new items recently presented at the #JavaOne conference in San Francisco. There, the main emphasis was on describing the new features available in #Java8, which is the default download version of #Java and will replace Java7 in 2015. Topics were

1.JSON reader as part of the language into JsonStructure; Tim talked about the new structures to read, write and update Json structures.

2.Async processing within an HttpServlet. This makes it easier to write code to minimize the risk of blocking a thread when either reading or writing to other services.

3.avatar.js – server-side only JVM using structure like node.js. Facilitates structures in which java threads communicate with the node app by making calls to it and then waiting for a callback.

4.avoiding SQLlinjection – a way to hack into sites taking advantage of the jsessionID cookie which is used so you don’t need to relogon to each page. Using this cookie, however, opens a vulnerability using a ‘cross-site request forgery’ in which an infected page posts a request for an unauthorized transaction using information it reads from the cookie.  Solution: create a custom header which includes a secret token as a hidden input that was originally from the secure web site. Add the token to the header when you do a post response. But you don’t need to protect all your pages, just those vulnerable to unauthorized transactions.


5.JavaFX – replacement for Swing: 3d support, printing, new controls, CSS improvements, GPC acceleration on Linux,… create shapes wrap them with images to make an object. Can also translate in a direction, rotate around an axis, etc. Separate object from the motion controller. Tim walked through code showing how easy it is to animate objects.

6.on mobile – can use JavaFX port to Android and IOS. Special APIs to access GPS, etc. does not require a separate VM download. Sources: roboVM – iOS and lodgON for Android

7.internet of things – e.g. Thalmic Myo – sensor on your arm ; Leap Motion – sophisticated APIs (two hands and a pointer device); TheEyeTribe – looks at your eyes and tell you what you are looking at. ; Parrott AR.Drone 2.0 ; NAO robot – all run using Java

For the videos see:


posted in:  Android, iOS, New York Java Meetup    / leave comments:   No comments yet

Mobile A/B testing and more

Posted on October 23rd, 2014

UX + Data

10/23/2014 @ Pivotal, 625 6th Ave, NY

Matt Weber presented a template for surveying user experience and Zac Aghion @Splitforce talked about his work on mobile A/B #testing


Matt introduced a template questionnaire on #UX he has developed for his students. To retain the flavor of the experience, the questionnaire concentrates on the most recent time an action was performed. It also considers the experience before, during and after the action/decision. He also spoke about his analysis of the results which develops themes for each of the three time periods: before, during and after.

Template is available at and is licensed under creative commons.

Zac talked about how A/B testing (testing which of two applications is more successful) on mobile devices is different from testing web pages. Issues include languages: javaScript vs Objective-C/Java and the uncertainty of connection during a mobile session.

The logic behind the experimental design and testing is the same, but these issues affect the complexity of implementing the test and the data collected

  1. The app may need to collect and store user interaction data while offline. Only later is it transmitted once an online connection is available
  2. Fewer off-the-shelf tools for mobile A/B testing and the different character of Objective-C/Java vs. JavaScript means more programming effort to implement a test
  3. Greater variability in the environment in which the user experiences the interaction. This may be either a positive (location data could eventually provide additional control variables) or negative (distractions and time constraints could add extraneous noise which makes it harder to see the signal in the data)


Zac presented two examples of A/B testing on mobile devices: 1. Two different format of buttons to access more detailed recipes 2. Whether eliminating a message box increases the number of in-app purchases.

Splitforce collects hardware and system setting information – operating system, language setting, etc.

In the two studies presented they did no collect the click path or other context information.

posted in:  Android, data, iOS, UX    / leave comments:   No comments yet