Would crash if an unsupported file was tapped twice because it would set the inFileBrowser boolean to false, thus leading to the attempt to launch said unsupported file. Fixes this.
Also made it display a brief toast if no cores support the extension of the file.
location API only provides horizontal API but iOS/OSX API supports
both horizontal and vertical. Maybe consider implementing vertical
accuracy for Android by hand later
and get_longitude are gone now in place of get_position. Basically,
from C land we basically do a poll-style queries, but on the
implementation side (ie. Android/iOS/OSX) - they all use callback-based
location updates. So we simply check in the poll function (get_position)
whether position has changed, and if so, update the pointer values and
return true - if not, set them to 0 and return false.
onResume/onPause/onStop/onDestroy. Doesn't seem to work yet and camera-based
core still crashes when unfocusing app. Might need to do calls back to JNI
shim functions to deinit some stuff or vice versa
baking that in as a dependency now by providing the .jar file.
Still need to write stub driver in C that calls these location functions through
JNI - and still need to gather all semantics for libretro API additions
Allows showing the dialogs without the need for an actual variable or ugly "new HistorySelection(fm, tag).show();" syntax.
Also moved the else if for "Quit Retroarch" to the bottom of the if statements so its structured relative to the UI.
- both MainMenuActivity and RetroActivity are single instances now
- AKEYCODE_BACK gets eaten and onBackPressed in Java is triggered
- onBackPressed right now calls an instance of MainMenuActivity
(reuses the existing activity on the stack)
- User can switch back and forth between RetroActivity and MainMenuActivity
with AKEYCODE_BACK / Back button
- When a subsequent intent is launched after RetroActivity has already been
started up once, the pending intent gets passed to the existing RetroActivity
throug onNewIntent - in C land it will look every frame if an intent is pending - if it is, it will look up certain variables through JNI to launch a new game - or whatever it is that the intent wants to do
- With this we can now switch seamlessly between Android UI and RetroArch
itself.
* pthread_key_create is used to set a destructor for every thread
created through jni_thread_getenv
* To grab a JNIEnv pointer - go through jni_thread_getenv
* jni_thread_getenv sets pthread_setspecific for the JNIEnv pointer
to bind destructor
* Reuse activity->vm everywhere instead of creating local pointer
copies
* Don't use DetachCurrentThread outside of platform_android's (new)
jni_thread_destruct function - the destructor will do this for us
now
- The UI is now mostly Fragment-centric (finally!)
- The Load Core, Load Game, Load Game (History) are now DialogFragments.
- The directory activities are killed off and consolidated into one fragment named DirectoryFragment.
DirectoryFragment is now a self-contained instantiable DirectoryFragment that can be instantiated anywhere by doing roughly the following.
DirectorFragment dFrag = DirectoryFragment.newInstance(/* Resource ID for a string title here*/);
dFrag.show(getFragmentManager(), "tag");
There are also other methods that were modified within the DirectoryFragment, such as addAllowedExt and disAllowedExt being changed to support a variable amount of arguments. This way, multiple calls of the same function aren't necessary in the case of adding multiple extensions, as well as supporting the case where only one extension is added.
DirectoryFragment also has a new interface added to it called OnDirectoryFragmentClosedListener. Say you have a DirectoryFragment instance, but want to use the selected item's path for something *after* the dialog has closed, with this interface, it is now possible. Just implement this interface within an Activity or Fragment, and then set the DirectoryFragment to use the listener through setOnDirectoryFragmentClosedListener() method.
Now what happens if this isn't set, wouldn't it be pointless to even use a DirectoryFragment in this case?
Not necessarily. What if you only wanted to save the selected item into the applications SharedPreferences?
This is a situation where it would be unnecessary to need that interface. So, to make a DirectoryFragment.java for the sole purpose of saving a selected directory/file path to the SharedPreferences, you would do this:
DirectoryFragment dFrag = DirectoryFragment.newInstance(/* Resource ID to a string title here*/);
dFrag.setPathSettingKey("key to store value in SharedPreferences at");
dFrag.show(getFragmentManager(), "tag");
Outside of these major changes, large portions of the code outside of this were simplified.
