All posts by

RxJS Observable – forkJoin with nested observables

This is really just for archive sake, but since it took a bit of looking into, I thought it worth posting since I hadn’t actually found the answer anywhere.

If you want to fire off several observable objects async but have to wait until they’re all completed before moving on, you’ll want to give the static forkJoin method a look.  ForkJoin will take an array of observables, execute them and give you back an array of their results when all have completed.

Unfortunately, if you’re using a version of RxJS that’s previous to 5.0, nested observables will complete their task, but forkJoin will not see it without a subscriber.complete() call from the observables that have a nested observable.  This is because RxJS does not have a complete() method on the Observable object until 5.0.0 alpha.1 (as of this writing, i’ve tested with 5.0.0-alpha.1 and 5.0.0-beta.11 successfully).  Once I was able to call “complete()” from the observable that was added to the forkJoin initially, the results were returned successfully.

Conclusion (because that sounded confusing): If you have observables that rely on other observables (nested), they must call “complete()” on the subscriber for forkJoin to realize the jobs are complete.

See the Pen RxJS Observable – forkJoin Example by John Grden (@neoRiley) on CodePen.

Thanks to Brian Troncone for the original JSFiddle

Have a bandit day!

Measuring Text in HTML5

For a while now, I’ve been doing quite a bit of work in HTML5/Javascript/CreateJS.  While the work is enjoyable, dealing with getting the bounds of a text field seems to have many solutions.

I’ve read through just about every one I could find (and believe me when I say –  there are many), looked through examples and did many tests.  After all that, I’m sharing my final solution for getting the bounds for a string:

Example call:


I give some credit to schickling on stackoverflow (only 6 votes?!) for the main inspiration as he aptly identified what I think is the key component: document.createTextNode()

I’d been using JQuery and wanted a solution that worked without a 3rd party tool.  The only thing that reliably gave me the same bounds as JQuery is the above method.  I’ve added debug support should you want to verify that it is indeed testing your string correctly.


Have a bandit day!

Parceler: Say good-bye to all that boilerplate code

On Android, if you like typing tons of lines of boilerplate for every property in your Parcelable classes, then this article is not for you.  So, go about your business citizen.

However, if you would like to create your class with 2 tiny additions and call it a day, you’re gonna love this post!

UPDATE – thanks to the author, John Ericksen, for pointing out that Parceler does not actually create equals and hashCode methods.  I have updated the examples and the post to properly reflect this

Parceling is one technique for passing objects from one context to another in Android apps.  To pass the objects along, they must implement the Parcelable interface and you’re forced to implement the methods and type all of that boilerplate code in-between.  In many cases, your objects may contain tons of properties and that equates to exponential typing.  In order to deal with such boilerplate code, we implement rules at Dreamsocket like organizing the properties in alphabetical order because of the requirement to write to and read from the parcels in the same order, and I’m sure you’ve developed your own methods of trying to drudge through copy/pasting the properties in as fast and efficient a manner as possible.

While Android Studio does a great job in helping generate the necessary methods to implement, this solution is a massive waste of valuable time and prone to mistakes.

Introducing Parceler.

Parceler is a code generation library that generates the Android Parcelable boilerplate source code.

In a nut shell, add the @Parcel  annotation to your POJO and a blank constructor (UPDATE:  a blank constructor is necessary ONLY when another constructor with parameters exists – otherwise, you can drop the constructor completely), and you’re in business.  What’s that you say??  Impossible?  Take a look at a comparison between these 2 versions of the same object called “Jedi”.  The first version implements Parcelable along with all of its methods and the other is a Parceler version of the same object structure:

Parcelable version (64 lines of code):

Parceler version (16 lines of code):

Essentially, Parceler is creating a Parcelable wrapper class for use with Parcels.wrap() and Parcels.unwrap() static methods at runtime, while your original class is left as is.

Now, when you’re ready to use Parceler in production, create your Parcelable with Parcels.wrap() method:

and then use Parcels.unwrap() to retrieve your object:

Parceler also offers a level of consistency between developers.   For example, a seemingly harmless action of how to read/write booleans can be achieved in several different ways.  This stackoverflow example shows how easy it is for a team of developers to approach something this simple and yet come up with several different implementations.  Parceler eliminates these types of issues.

For more information on Parceler and it’s many features, head on over to its Github repo and check out the readme

Have a bandit day!