On 12/13/16, Antonio Scuri <antonio.sc...@gmail.com> wrote: > Hi, > > First I need to understand a little bit more about how Android does > things. We can then adapt the IUP structure so it will be able to suit your > needs. > > So after you create the native element, you tell me that you have to wait > for an event when the element is actually created. In between can you set > any properties on that element? > > I mean, what's the point in creating the element but it is not actually > created at that time? What you can do after that and before the event? > > Can you send me a simple example in C for an Android application? So I > can see how this creation process takes place. > > Best, > Scuri > > > On Tue, Dec 13, 2016 at 8:00 AM, Eric Wing <ewmail...@gmail.com> wrote: > >> Hi, I'm trying to prototype an Iup implementation for Android. I have >> implemented a basic Dialog and Button to try to get things going. But >> I realized there is a design problem that is blocking me... >> >> I am making IupDialog correspond to an Android Activity. By itself, >> this seems to work. However, the moment I try to add a widget to it >> (e.g. button), I realized there is a problem. >> >> When I create a new Android Activity, I do not get back an object >> immediately. I have to wait for the system to create the Activity some >> time later after this procedure returns. So in the Iup Dialog map >> function callback, I can create a new activity, but I cannot yet set >> the Ihandle->handle to anything yet. >> >> Meanwhile, I expect the Button map function callback to be invoked, >> but it appears that IUP's internals are skipping this because my >> ih->handle for the parent is still NULL. >> >> It appears that I need a way for IUP to defer its processing for >> IupShowDialog/IupMap until after I notify it that I got the OS event >> for the Activity creation, or I need a way to force re-run all the >> processing once I do get the OS event for the Activity creation. >> >> Can you give me some suggestions on how to deal with this? >> >> >> Thanks, >> Eric >>
So I think I have an overly clever workaround which seems to work (at least first glance). So maybe we don't need to worry about this one. Quite frankly, Android is pretty awful. It is over engineered and has many places that are way harder than it should be and creates ton of confusion for developers in general. You can Google or check Stack Overflow just to see how much confusion fairly simple things generate. e.g. Passing data between Activities, figuring out when the Application is backgrounded, application life-cycles (and worse, fragment life-cycles), etc. (I just read another called "Don't Store Data in the Application Object" which is actually quite terrifying for anybody who actually expects their variables to actually stay in memory and not be lost while their program is still running.) In this case, Activities are kind of like different views or windows, but Android made them much more complicated than that and they are almost like separate processes (but not exactly that either). And Android made it really hard to communicate between Activities because of this. Yet an Activity is a core tenet of Android and you must deal with them, especially as we talk about "native Android UI". So when you start a new activity, you call a method called startActivity. This is a kind of like a system request and you don't get back an object by calling this method. Instead, you subclass the Activity class and you request that type be created with startActivity. Later in time when the OS decides, the Activity will be instantiated. Then in the Activity subclass's onCreate callback, you now can do stuff like get the "this" reference. The way you communicate between Activities is indirect too. You must go through another class called the Intent. It allows you to pass Java serializable objects through it via key/value pairs. In practice, it is clumsy and most of the interesting objects (like anything related to the Android view classes are not serializable). Anyway, I think I have a workaround that probably violates every principle they tried to over-engineer. When I start a new activity, I also create a root GroupView (which in my case is an instance of their RelativeLayout manager which I intend to make interoperate with IUP's layout system. (Also note, the AbsoluteLayout class is already deprecated which might of been more straight-forward with IUP, but is kind of par for how Android likes to over-engineer things.)). I originally was going to create this root view with the onCreate callback method since I must attach it to the new Activity, but I discovered I can create a detached GroupView and use it as a stand in for Ihandle->handle. The button will now get Mapped and put into the GroupView which gets me around that original problem and still seems to work. Then the final trick is to figure out how to get the GroupView attached to the Activity (and swap the handles around) at the right time. So here is the really dirty trick. GroupView is not serializable so I can't pass it through an Intent. However, since I am using C and JNI, I can do things nobody expected me to do. I can pass the C pointer address to the Ihandle (as a Java long) through the Intent. In the Activity OnCreate callback, I can convert back the Java long to the pointer address and go back through C/JNI to get me the Ihandle->handle which has the saved Java reference to the GroupView. I can then attach the view and swap the pointers around. Thus, I effectively passed a non-serializable Java object between Activities. As for setting properties on the Activity before it is created, I'm not sure...I suspect that I'll have to wait for the onCreate callback, and then go through the list of different IUP properties and set them there. I hope that will work. Now I think this problem is only for Activities. Button works much more like you expect. You create a new object and get it back immediately. Anyway, I plan to show you this code pretty soon once I get a few more things implemented in the Button and Activity to make sure the design actually works. As for a minimal C example, you can look at: https://bitbucket.org/ewing/nativeandroidexperiments However, be aware that in Android, there really isn't anything as a pure C example. You are required to use Java for all the native UI elements. So there is a lot of JNI in C example like this one as well as Java classes. 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
