If you are building a mobile application of any sophistication, you are likely to need some services to support your app. You’ll need a way to distribute your app for testing prior to submitting to the app store(s), as well as analytics, error logging, crash reporting, and possibly user and data management services. Of course, you could write these services yourself and provision servers to host these services, but why do that when you don’t have to?
Your company needs a mobile app and you want to save money (of course). You want the app live last week, and you’d really like to avoid hiring Android and iOS devs on top of your existing web team.
Kotlin is a JVM language that hit version 1.0 about a year ago (February 2016).
It is developed by JetBrains, the same people who make my favorite suite of
IDEs. The language itself is open-source under the Apache License 2.0 and is
developed as a community project over at kotlinlang.org. Kotlin is something
that I have become rather excited about over the past year. This post’s goal is
not to teach you Kotlin but to get you excited about it!
Pixel density is the number of pixels per linear physical unit. Measured in pixels per inch (ppi or dpi). Pixel density and resolution are technically the same thing, but often people say “resolution” to mean “pixel count,” a related metric:
count = densityH * width * densityV * height
When other things are held constant:
Working as developers, we are focused on the low level technical details of a product, being that a website or an app. This heads down approach often makes us not to pay attention to many high level details that are crucial to bring our product to success. The typical path for a developer, at least at the beginning, is to build an app, put it on the store and then see it fail miserably. If that has happened to your app, then this post is for you!
Howdy, lazy bum! Enjoying the ReactiveX magic? Want to take a look at polling?
I’ll be walking you through a solution I put together for one of our up and coming apps! It works rather well, I learned a lot, and so far no complaints…although there are no users yet either!
Feeling quite charitable, I’m going to let you in on some useful bits and pieces as we build up to polling: threading, late subscribing, replay, manual re-triggering and error handling (a must for preserving replays).
I work from all over the place: Home, on public transit, the office, coffee shops, etc.
A big challenge to developing android apps in an environment where my laptop and phone are on different networks (wifi vs. LTE, or laptop tethered through phone) is the inability for my phone to see the API server that is often running locally on my laptop. Here is a simple tip to allow your phone to hit the backend over ADB and a usb cable.
For the past year, I’ve been working mainly with AngularJS and before that Ruby on Rails. I’ve never heard of Meteor until a few weeks ago. I am intrigued by the idea of tightly connecting the client and server together in a synergistic manner that allows for fast responsiveness, which is what Meteor is all about. I decided to go through Meteor’s tutorial online and get a feel for why the framework differentiates itself from other current technologies. From a very high level perspective, Meteor is a very good solution for quickly building an application from the ground up and provides some cool features out of the box.