I am newbie on BlackBerry. How do I achieve (in BlackBerry) the same as that of Android\'s
intent.putExtra(\"key\",\
create one public class,
public class Values
{
public static String value1 ="";
public static String value2 ="";
}
Now u can access the value1,and value2 in anywhere.
before push the next screen, assign the values.
public class MyClass extends UiApplication
{
MyClass mc = null;
public static void main(String args[])
{
mc = new MyClass();
if (MyClass != null)
{
mc.enterEventDispatcher();
}
}
public MyClass()
{
Values.value1 ="HI"
Values.value2 ="Welcome"
this.pushScreen(new SplashScreen());
}
In another class u can access it.
public class Splashscreen()
{
public Splasscreen()
{
if(!Values.Value1.equalIgnoreCase("")
{
Syso(""+Values.value1) ;
}
}
Using public static
variables (as in Ganesh's answer) will work, but in general, that's not an object-oriented pattern that I would recommend.
Luckily, this can be easier in BlackBerry than in Android. Android's Intent
mechanism is actually somewhat unnatural to many Java developers. When one Activity
starts another Activity
via an Intent
, it does not actually new
up (create) the instance of the second Activity
, and it also doesn't hold a normal Java reference to that object. If it did, this problem would be much simpler. Android's implementation forces you to use the intent extras mechanism.
If your old ActivityOne
class becomes ScreenOne
for BlackBerry, and ActivityTwo
becomes ScreenTwo
, then you can just do something like this:
public class ScreenTwo extends Screen {
private String _value1; // this doesn't have to be a String ... it's whatever you want
private String _value2;
public void setValue1(String value) {
_value1 = value;
}
public void setValue2(String value) {
_value2 = value;
}
}
Then, in ScreenOne
, you can start ScreenTwo
this way
ScreenTwo nextScreen = new ScreenTwo();
nextScreen.setValue1("This value one for ActivityTwo");
nextScreen.setValue2("This value two ActivityTwo");
UiApplication.getUiApplication().pushScreen(nextScreen);
That's actually more consistent with the way Java objects normally are used, and interact with one another.
There's good reasons why Android made Intents
and extras, but in BlackBerry, you just don't have to worry about that.
Edit: I'm trying to consider what I think is the motivation behind Mr. Smith's comment below. If you actually like the Android Intent
extras mechanism in the sense that you can pass multiple data types from one Activity
to another, as key-value pairs, then you can certainly achieve something similar in BlackBerry. Instead of the ScreenTwo
code above, you could use this:
public class ScreenTwo extends Screen {
private Hashtable _extras;
public void putExtras(Hashtable extras) {
_extras = extras;
}
}
Where you put(Object, Object)
key-value pair data into a Hashtable
passed to the called screen, and then read it when you need it. Or even:
public class ScreenTwo extends Screen {
private Hashtable _extras;
public void putExtra(String name, Object value) {
_extras.put(name, value);
}
}
This is something worth designing well once because you'll end using it on most projects.
To begin with, no there's no built-in mechanism such as Android's in BB, but you can (and should) code your own:
public class MyScreen extends MainScreen {
public void updateParams(Hashtable params){
// Read from hashtable and cast
// Update fields (on Ui thread)
}
}
As you can see, I've used a hashtable because it is the most flexible way. You could use setters, but then you'd be coupling the calling screen to the updated screen class. This allows you to pass a single or several parameters. You could have used a Object[]
, and thus save a few references, but that optimization hardly pays off and you would be coupled to the array's lenght as well as to the order of objects inside the array. Now, to pass two params to a screen, you would do:
Hashtable ht = new Hashtable();
ht.put("somestring", "Hello!");
ht.put("someint", new Integer(3));
MainScreen ms = new MyScreen();
targetscreen.updateParams(ht);
// Now push screen
You could also create a constructor like this:
Myscreen(Hashtable params)
But this forces you to create a new instance each time you need to update the screen with new data. With the method, you could update a screen which is already on the stack.
This is an approach you could reuse in many projects. In fact, most times you'll end subclassing MainScreen anyway to abstract and simplify repetitive tasks like Menu creation and handling key presses, so this would be a part of that subclass.