Android Question DropboxSync API - Inconsistent Results Using Emulator

[DaveB4A]

I started down the "Dropbox" path as an "easy way" to "simulate" data file input from a remote source to my application. (I think something like RDC to a file on my local PC is probably a better "simulation" method - but Dropbox appeared like an easier route for testing - as I don't have any experience (yet) with RDC.)

When I initially set up the "Dropbox" link - I spent many hours trying to get it to work only to find out (THANKS to Erel) that the DropboxSync API would not run on the Genymotion emulator... Which was the emulator I've used to develop all of my "test" apps so far.

Erel suggested using B4A Bridge instead - and that seemed to work fairly well. But the device I used to test is also the source of my "internet connection" - so I can't use the device for B4A Bridge service and be connected to the internet at the same time.

So I created another emulated device - this time using the Android AVD Manger. Using this emulator (with the same Dropbox test application) the results are highly inconsistent.

Sometime (perhaps 2 out of 10 attempts) when "LinkAccount" executes - the "approve connection validation prompt" appears on the emulator screen, you respond to it and my application works exactly as expected. You can modify code, reload the app, etc. and it works flawlessly.

The other 8 out of 10 times, the "validation prompt" never appears. Instead you get a JAVA NullPointerException.

java.lang.RuntimeException: java.lang.NullPointerException


    at anywheresoftware.b4a.dropbox.DbxAccountManagerWrapper.LinkAccount(DbxAccountManagerWrapper.java:91)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at anywheresoftware.b4a.shell.Shell.runVoidMethod(Shell.java:520)
    at anywheresoftware.b4a.shell.Shell.raiseEventImpl(Shell.java:235)
    at anywheresoftware.b4a.shell.Shell.raiseEvent(Shell.java:174)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at anywheresoftware.b4a.ShellBA.raiseEvent2(ShellBA.java:93)
    at anywheresoftware.b4a.BA.raiseEvent(BA.java:154)
    at b4a.example.processingservice.onCreate(processingservice.java:45)
    at android.app.ActivityThread.handleCreateService(ActivityThread.java:2363)
    at android.app.ActivityThread.access$1600(ActivityThread.java:130)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1277)


    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:137)
    at android.app.ActivityThread.main(ActivityThread.java:4745)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
    at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
    at anywheresoftware.b4a.dropbox.DbxAccountManagerWrapper.LinkAccount(DbxAccountManagerWrapper.java:89)
    ... 21 more

When the emulated device is launched each time, I choose "Wipe User Data" so the device should "look" to B4A exactly the same each time I begin working in B4A.

So, my question is... Is there "reference material" somewhere that specifies why various emulators behave differently - and how one should chose the "best" one - for consistent results...

 

[Erel]

What is your device type? Why don't you use USB debugging?

 

[DaveB4A]

I appreciate your reply. The device currently in use is a Samsung Galaxy.

As far as "USB debugging" - I've never investigated that as a possibility - but I'll do some research and see if that might work as an interim solution.

In a broader sense, my question really focuses on what is the "best practice" for standardized development with B4A / Android. I'm really trying to understand the "inconsistencies" and why they occur so that I can develop a suggested course of action. Today, I'm simply too ignorant of the Android environment to formulate a theory - but hopefully some additional research and testing in that department will help.

For example, imagine a classroom of 30+ students who are currently learning to develop applications for Apple devices. Everyone uses the same "toolset" (XCODE) and the same "emulator" (iOS Simulator). While this may or may not be an "optimal" situation - at least the teaching / learning environment is consistent - so progress can be sustained without too many "bumps" in the road.

Now, suppose those same students want to "learn" Android development. While I realize that ADT/Java is the "equivalent" solution - I chose to experiment with B4A simply because I have good bit of experience with VB/VBA. (Thinking this would reduce my "learning curve" and allow some rapid prototype development.) However, I'm having difficulty imaging why some things won't run in certain emulators, and why some emulators are "inconsistent" in their behavior.

As I said, I will look into using "USB debugging" for my own personal learning. But, in the longer term, there is no way I can see a classroom learning / development environment being successful where everyone uses different emulators or has to utilize their own unique device. Hence my question for experienced Android developers (and possibly classroom style teachers or those who have instructed in a seminar style setting) regarding what is the "best" configuration for stable, consistent learning.

Thanks, again, for all of your help. I appreciate it.

 

[Erel]

These issues are not related to B4A. You will encounter the exact same Emulator / Virtual machine anomalies if you develop with Java. Both call the same APIs.

I'm sure that you know that the Android emulator is part of the Android SDK.