Bundler
Generates broilerplate code for intent and bundle builders and parsers. Autogeneration of this code at compile time ensures type-safety. Here's an example of this in Action.
@RequireBundler class BookDetailActivity extends Activity {
@Arg @State
int id;
@Arg @State
String name;
@Arg @Required(false) @State
String author;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_book_detail);
Bundler.inject(this);
// TODO Use fields...
}
@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
Bundler.restoreState(this, savedInstanceState);
}
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
Bundler.saveState(this, outState);
}
}
After defining the annotating the activity methods are added to the 'Bundler' class which help in building and parsing the intent for the activity. The above activity can be started as follows:
Bundler.bookDetailActivity(1, "Hitchhiker's guide to galaxy")
.author("Douglas Adams")
.start();
Two classes are generated by the annotation processor. One Bundler
class is generated which has the inject
, restoreState
and saveState
methods of all annotated classes. And one BookDetailActivityBundler
class is generated for BookDetailActivity
. Here are the generated classes: BookDetailActivityBundler, Bundler
As you can see defining intent keys and parsing intents is not needed anymore. See Why Bundler? for a detailed explanation. State is also saved to bundle and retrieved backed.
If in future if the field id
in BookDetailActivity
for some reason has to be changed to type String
then the class Bundler
is regenerated and all the places where an int
is being passed to the BookDetailActivity
will throw a compile time error compared to the run time error it would have lead to in the normal scenario. The process for annotating Fragments and service is similar, but instead of .start()
method fragment's builder will have .create()
method. Here's an example for a fragment
@RequiresBundler class BookDetailsFragment extends Fragment {
@Arg
int id;
@Arg
String book;
@Arg @Required(false)
String author;
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
Bundler.inject(this);
// TODO inflate and return the view and use the fields
}
}
The above fragment can be created as follows:
BookDetailsFragment fragment = Bundler.bookDetailsFragment(1, "Harry Potter")
.author("J. K. Rowling")
.create();
This would create a BookDetailsFragment
that have arguments set to the above values.
The process of documenting and writing tests is on going. The library is currently being used in our app Define and another library Portal. Any PRs, suggestions are more than welcome.
Download
Gradle:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
}
}
apply plugin: 'com.neenbedankt.android-apt' ext {
bundlerVersion = '0.1.1'
}
dependencies {
compile "in.workarounds.bundler:bundler-annotations:$bundlerVersion"
apt "in.workarounds.bundler:bundler-compiler:$bundlerVersion"
// if using Parceler library then uncomment
// compile "in.workarounds.bundler:bundler-parceler:$bundlerVersion"
}
@Arg
or @State
?
What can be an The short answer is anything that can be put into a Bundle
. All primitives, String
, any object that implements Parcelable
, Serializable
, ArrayList<Parcelable>
, ArrayList<Object>
(as ArrayList
implements Serializable
) can all be annotated with @Arg
or @State
.
@Arg
and @State
Custom Types for If for some reason you have a type that cannot be made a Parcelable
or it has a different mechanism to serialize data that the library is not supporting, you can define your own custom serializer for the type. Let's consider the simple example of Date
object, it can't be put into a bundle directly, but it'd be nice if the calling code and the activity can directly use the object as Date
@RequireBundler public class DemoActivity extends Activity {
@Arg
Date date;
@Override
public void onCreate(Bundle savedState) {
setContentView(R.layout.activity_demo);
Bundler.inject(this);
}
}
The above code gives a compile error saying Date
is an unrecognized type. To overcome this you can define your own Serializer
that knows how to put and get a Date from a bundle. Here's a possible implementation of the serializer:
/** * This class must have an empty constructor which will be used to instantiate this. */ public class DateSerializer implements Serializer<Date> {
@Override
public void put(String key, Date value, Bundle bundle) {
bundle.putLong(key, value.getTime());
}
@Override
public Date get(String key, Bundle bundle) {
return new Date(bundle.getLong(key));
}
}
Now while using @Arg
for the Date date
field, provide an argument to @Arg
telling the library to use DateSerializer
as the serializer. In the above DemoActivity
change:
@Arg(serializer = DateSerializer.class)
Date date;
Now this activity can be started directly by passing date to it's builder as below:
Bundler.demoActivity(new Date(System.currentTimeMillis())).start();
A serializer is already included in the bundler-annotations
package for serializing List<? extends Parcelable>
.
@Arg(serializer = ParcelListSerializer.class)
List<Foo> foos; //where Foo implements Parcelable
For putting a type annotated with @Parcel
from Parceler library add the depedency
compile "in.workarounds.bundler:bundler-parceler:$bundlerVersion"
This artifact containes a serializer ParcelerSerializer
use it as follows:
@Arg(serializer = ParcelerSerializer.class)
Dog dog; // where Dog is annotated with @Parcel
@RequireBundler
Additional options to The @RequireBundler
annotation accepts four arguments:
-
requireAll (boolean defaults to true) when set to true all fields are assumed to be as required unless specified using
@Required(false)
, similarly when set to false all fields are assumed optional unless specified using@Required(true)
. This is there just for convenience if you have more fields that are required set this totrue
and if you have more optional fields set this tofalse
-
bundlerMethod (String defaults to "") this is to specify the name of the method that corresponds to this class in the generated
Bundler
class. The aboveBookDetailActivity
by default generates a methodBundler.bookDetailActivity(...)
, but you can specify a different name by annotation it with@RequireBundler(bundlerMethod="detailActivity")
this generates the methodBundler.detailActivity(...)
which can be used to start the activity. This is also useful when there are two activities with the same name. If there are twoBookDetailActivity
s in the project you have to specify a different name for atleast one of them. -
inheritArgs (boolean defaults to true) If the super class of the current class is also annotated with
@RequireBundler
and the super class also contains fields annotated with@Arg
then those fields will also be considered as arguments of current class. Discussed further below. -
inheritState (boolean defaults to true) Similar to
inheritArgs
. Fields in the super class annotated with@State
are also saved and restored in the subclass.
Inheritence
For example, consider the following classes BaseActivity
and ChildActivity
@RequireBundler(requireAll=false) public class BaseActivity extends Activity {
@Arg
int first;
@Arg @Required(true)
int second;
@Arg @Required(false)
int third;
// rest of the class
}
@RequireBundler(inheritArgs=true) public class ChildActivity extends BaseActivity {
@Arg
String fourth;
// rest of the class
}
The above code leads to two generated methods in Bundler
that can be used as below:
// passing first and third values is optional Bundler.baseActivity(2).first(1).third(3).start(ctx);
// only the value of field second needs to be passed to start the activity Bundler.baseActivity(2).start(ctx);
// passing third is optional Bundler.childActivity(1, 2, "4").third(3).start(ctx);
// where as first, second and fourth are required to start the activity Bundler.childActivity(1, 2, "4").start(ctx);
In the above code the activities are started by passing the values first = 1
, second = 2
, third = 3
, fourth = "4"
and ctx
is Context
object.
Few things to note here are:
- the order of fields in the generated method is parent fields followed by child fields in the order they are defined.
- the global
requireAll
behavior is not inherited, where as the field-wise@Required
behavior is inherited. So if it's required thatChildActivity
does not require the fieldsecond
to be necessarily passed in the intent then simply redefine that field inChildActivity
as follows:
// inheriArgs is true by default @RequireBundler public class ChildActivity extends BaseActivity {
@Arg @Required(false)
int second;
@Arg
String fourth;
// rest of the class
}
ChildActivity
can now be started as
// passing second and third is optional Bundler.childActivity(1, "4").second(2).third(3).start(ctx);
// only first and fourth are required fields Bundler.childActivity(1, "4").start(ctx);
License
Copyright 2015 Workarounds Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.