Hi all, I've pushed up my initial prototype to Github https://github.com/ewmailing/IupAndroid Look at the Android branch.
I know Android code can be really hard to understand for those not familiar with it, especially with all the JNI. I think I should give a walkthrough description of the architecture at some point, but I wanted to let you guys look over something in the meantime. (I actually need to shift gears for the next few days.) Maybe you can ask questions which will help me figure out how to explain it better. I do encourage you to look at my Git commit logs. They do try to explain some things. The IUP test program is in main_c.c. It basically just creates a Dialog with a Button. Clicking the button will create a new Dialog (with title bar) and Button. This is intended to behave with the normal Android navigation model. When a new Activity gets created, it pushes the new one on your screen. You use the back button on Android to close the current activity and go back to the previous one. (That is one of the core ideas I have in trying to make IUP fit the native Android experience. And I'm thinking of something similar with iOS NavigationViewControllers if this works out.) Backing out of the last Activity will exit the program. I do not have layout working. (I did make screen rotation not do the stupid thing though...another stupid Android decision was to cause device orientation to completely quit and restart your app by default, which I don't think is *ever* useful for a real app.) There is lots to talk about. The first major thing is we need to talk about the event loop. I want to discuss this in more detail when I get back to this, but the crux of the matter is that Android does not let you control the event loop, so IupMainLoop is not possible to support. (And as I said earlier, I am deliberately not putting IUP on a background thread, so that is off the table.) Instead, you must deal with Android's event driven system. I temporarily hacked in a callback entry point called IupEntry(). Other platforms such as Mac and iOS actually prefer you to work like this (and trying to take over the event loop usually leads to subtle bugs). And Emscripten/ASM.js/WebAssembly also requires this because you are not allowed to block the JavaScript event loop. So I have some ideas about introducing a new start up convention/API for IUP programs (and some ideas on how to also not break existing programs to support a smooth transition). I have a list of other things to discuss talking about both Android-isms and mobilisms (like how apps don't necessarily quit on these systems, but they just background), which I'll save, but I did want to say this one just to get the community to start thinking about this too. TableViews are possibly the most important widget on mobile (iOS+Android), but IUP doesn't seem to have a TableView API as far as I can tell. Android, iOS, and Mac all have native widgets for TableViews. (By the way, are there any plans for WinRT/UWP support?) Also, I noticed libui is currently trying to introduce TableViews and is asking for public discussion on it. Thanks, Eric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
