SourceForge has been redesigned. Learn more.
Close

Android porting

Stefano
2012-11-30
2014-10-21
<< < 1 2 3 4 5 6 > >> (Page 4 of 6)
  • Dante Loi

    Dante Loi - 2014-05-29

    Dear Davide
    I think that DialogParameter will be the only dynamic dialog, so we not need to share the size setting with other dialogs. Because the static dialog windows will be managed by the OS.
    BTW i had started to write a script to convert the different screen type layouts.

    Now the app is quite matures for the first unstable version, maybe we can add the DialogLayer, i've already write that but is not how i would like it and there are some details that keep more time...

    best regards,
    Dante

     
    Last edit: Dante Loi 2014-05-29
  • Davide Bucci

    Davide Bucci - 2014-05-30

    Dear Dante,
    I saw your commits.

    In the rev. 774, the Swing application does not compile anymore...

    Be careful editing files which are shared between the Swing application and the Android one, they must contain only code which is compatible with the two platforms! Most of the refactoring we did to ease the porting of FidoCadJ towards Android was directed towards separating platform-specific code from the one which is general.

    I propose to revert src/Globals.java back to revision 772 and we might eventually discuss how to separate the configuration variables of the Swing application (present but utterly useless in the Android one) from the ones of the Android application. Probably create a shared Globals class and one called SwingAppConfiguration.java for the Swing application and one called AndroidAppConfiguration.java for the Android one. If you need some Android-only configs, feel free to create AndroidAppConfiguration.java, but please do not add variables to Globals.java, for the moment.

    I saw also the changes done to the draw() method of the PrimitiveAdvText class. There is the same issue as for Globals, so please revert the code to rev. 772 there, or the Swing application can not be compiled...
    It seems quite strange to me that there are issues with the scroll related to the way the text is written on the screen. The graphic device context there should be the one of the drawingPanel (net.sourceforge.fidocadj.FidoEditor class) and the Android graphic system should prevent to write there. I do not know exactly which kind of an issue you were trying to fix, but my gut feeling suggests that the issue is probably elsewhere. I propose to revert to rev. 772 for this file, so that I can have a look at what it is happening.

    Concerning the opportunity to release a preliminary release, I suggest that the best thing we can do is to use the Android app for a while, just as regular users (for example to post schematics or drawings in forums) and see if there is something to fix.

    Best regards,

    D.

    P.S. Try to avoid lines longer than 80 characters

     
  • Dante Loi

    Dante Loi - 2014-05-31

    Dear Davide,
    I suspected this problem, however now I've restore like before.
    The bug fixed by the r774 is understandable by the attached images. The text rendering continue also when the text object is out of the drawing pannel, that dirties the tools bar...

    Anyway me too don't like that code, but is the first solution that i've thought...

    Best regards,
    Dante

     
    Last edit: Dante Loi 2014-05-31
  • Davide Bucci

    Davide Bucci - 2014-05-31

    Dear Dante,
    I will have a look, I have never seen something similar in the real device.
    Maybe an issue with graphic.android.GraphicAndroid?

    Cheers,

    D.

     
  • Dante Loi

    Dante Loi - 2014-05-31

    Dear Davide,
    this bug occurs also in my real device, and in many virtual devices.
    I can act in the GraphicAndroid, but i always need to know the context for get the scroll changes.

    Cheers,
    Dante

     
  • Davide Bucci

    Davide Bucci - 2014-05-31

    Dear Dante,
    I tried on the Note and I did not see the bug.
    This sounds quite strange. In my opinion, either there is a bug in the Android graphic system (improbable), or this means we are doing something weird, for example for the layout or the low level drawing code.

    Try to have a look at GraphicAndroid on your own (but do not change it for the moment, as there might be side effects). What do you think about the code? Do you see something strange there?

    Cheers,

    D.

     
  • Davide Bucci

    Davide Bucci - 2014-06-02

    Dear Dante,
    aha! Now I see... ]:-f

    So let's turn the HW acceleration off. In the meanwhile, I will se if it's possible to get rid of drawTextOnPath(), maybe by using graphic transform. I also have to handle the clipping regions in graphic.android.GraphicAndroid. It's the hitClip method, which is quite important to speedup partial redraws.

    Cheers,

    D.

     
  • Dante Loi

    Dante Loi - 2014-06-03

    Dear Davide,
    so well, i must still improve the DialogParameters because when i have disabled the virtual keyboard auto showing, is disappeared the cursor in the text fields. So i should find another method to do it.
    Morover, i had a look the swing DialogExport, i seems that would be better, write it entirely with java. BTW how you intimated, I will write in a separate class the dialogs setting, for make sharable this code by different dialog.

    Cheers,
    Dante

     
  • Davide Bucci

    Davide Bucci - 2014-06-04

    Dear Dante,
    for what it concerns DialogParameters, my experience with Java and other languages is that it is better not to change the usual ways things are done.
    If you customize the appearance of the keyboard, it might work at one particular moment with a particular version of the operating system, but it is deemed to become obsolete each time there is a change in the operating system directed in this way. So, it is somewhat dangerous since it requires quite a maintenance effort.

    For the DialogExport, in my opinion this is not indispensable for the moment for an Android application. Almost all the code needed for the export is present, but in my opinion it is better to concentrate the development towards an app which works perfectly, even if does not have straight from the beginning all the options offered by the Swing application.

    Cheers,

    D.

     
  • Davide Bucci

    Davide Bucci - 2014-06-07

    Dear Dante,
    I tried to get rid of drawTextOnPath() in the version of the drawAdvText() method of the GraphicsAndroid class, in revision 777. Does this eliminates the Android bug you have found with HW acceleration?

    I think I can eliminate drawAdvTextPath, which for the moment still contains the old code and I which I used to compare the two methods. Do you agree with that?

    BTW, I think that the new code is probably much faster. In my opinion, drawTextOnPath() is a bit tricky to implement and it is probably quite slow.

    Cheers,

    D.

     
  • Davide Bucci

    Davide Bucci - 2014-06-07

    Dear Dante,
    I noticed that if I am editing something in DialogParameters and I am rotating the device, the editing operations I have done are lost. Moreover, the dialog seems to lose the connection with the graphic element to be modified.
    Is this an issue that should be handled in FidoEditor.DialogParameters(), in your opinion?

    Cheers,

    D.

     
  • Dante Loi

    Dante Loi - 2014-06-11

    Dear Davide,

    I've tested the new drawAdvText() code, it works how must.

    Is this an issue that should be handled in FidoEditor.DialogParameters(), in your opinion?

    I think that the issue is inside the DialogParameters class. I'll try to fix it today...

    About the other new features: the grind is bad showed on nexus7 1200x1920...

    Dante

     
  • Davide Bucci

    Davide Bucci - 2014-06-11

    Dear Dante,
    I am wandering whether the problem of the screen rotation should be partially handled also in the methods and onRetainNonConfigurationInstance() and reloadInstanceData() of the FidoMain class.
    From the screenshot you posted, I think that it can be an artifact due to an undersampling (a sort of a Moiré pattern) which occurs when the emulator maps the 1200x1920 pixels screen into a smaller window. The result should be viewed on the real device to see if there is an issue.
    But on a such a high resolution device the grid points might be to small to be visible. I will have a look at the opportunity of increasing the size of the points when the resolution is very high.

    Cheers,

    D.

    Edit: Having a look at rev. 783, I noticed that you removed the "use_sensors_rotate_mirror" resource from the /trunk/bin/MessagesBundle_it.properties and /trunk/bin/MessagesBundle_en.properties:

    https://sourceforge.net/p/fidocadj/code/783/

    It sounds that there was a conflict between two recent commits we did. Can you please check that? BTW, if you add a resource to the MessagesBundle files, add it at the end of the file so that it is easy to be found by translators. Also add it in English language for all the languages, so no file remains incomplete (this would be detected by one of the automatic tests, if the resource is added to the Italian language).

     
    Last edit: Davide Bucci 2014-06-11
  • Dante Loi

    Dante Loi - 2014-06-14

    Edit: Having a look at rev. 783, I noticed that you removed the >"use_sensors_rotate_mirror" resource from the >/trunk/bin/MessagesBundle_it.properties and >/trunk/bin/MessagesBundle_en.properties:

    I didn't saw that... It seems ok. However i changed the prop* files as you hinted.

    I am wandering whether the problem of the screen rotation should be partially handled also in the methods and onRetainNonConfigurationInstance() and reloadInstanceData() of the FidoMain class.

    Maybe you're right, surely the solution not is in the DialogParameters... Maybe in the

        public void setPropertiesForPrimitive()
    

    method from the FidoEditor. But I didn't well clear that.

     
  • Davide Bucci

    Davide Bucci - 2014-06-15

    Dear Dante,
    I had a look and I think I understood what is happening.
    DialogParameters retains a reference to its caller (an instance of FidoEditor), in order to call saveCharacteristics on it. In fact, when the screen is rotated, the application is relaunched and a new instance of FidoEditor is created.

    The DialogParameters now has an outdated reference to the old FidoEditor which is no longer the active editor.

    I do not see any simple way to solve the issue. A possible solution is to make sort that just before saving the changes, DialogParameters asks to "something" the most recent and updated instance of FidoEditor available.

    That "something" might be a static class which will contain a reference to the most recent FidoEditor. I will give it a try, but it is not elegant at all, in my point of view...

    Cheers,

    D.

    Edit: I tried the solution described above and it works. There is a new static class called StaticStorage.java in the package net.sourceforge.fidocadj.storage

     
    Last edit: Davide Bucci 2014-06-15
  • Davide Bucci

    Davide Bucci - 2014-07-01

    Dear Dante,
    thanks for your last commit, the spinners are quite nice and useful.
    For the rest, in my opinion what it remains to be done is to make sort that the app retains the current state (drawing as well as configuration) when it is ended and restarted by the user or the system.

    Apart from that, it should be used in some real-world situations to see which needs to be improved and which bugs should be corrected.

    What do you think about it?

    Cheers,

    D.

     
  • Dante Loi

    Dante Loi - 2014-07-04

    Dear Davide,
    I've made some improvements that allow to support the app on Samsung Galaxy S3 and similar screen size (this devices are very spread).
    Morover the same improvement solves the problem of the toolbar visualization when is in portrait mode also with large devices.

    I don't think that save, ever the state of the app is the best thing to do. Because when a user want exit just a moment from the app uses the android home button, instead when he want exit definitely simply he saves and exits with the undo android button.

    Cheers,
    D.

     
  • Davide Bucci

    Davide Bucci - 2014-07-08

    Dear Dante,
    thanks for the commit. Now what I propose is that this evening I will try to post a preliminary version somewhere so other people can try it if they want.

    Cheers,

    D.

     
  • Davide Bucci

    Davide Bucci - 2014-07-08

    Dear All,
    I will put all the preliminary versions of FidoCadJ for Android here:

    https://sourceforge.net/projects/fidocadj/files/public_betas/Android/?

    I have just published the first one (you will have to tweak with the security settings of your device to install it).

    Cheers,

    D.

     
  • Dante Loi

    Dante Loi - 2014-07-11

    Dear Davide,
    Concerning the dialogs on small devices, we need to change radically the dialog's body. I thought to use a simple View instead of a DialogFragment.
    Because if I'd make smaller the dialogs, it'd unusable!
    An other solution could be not support the small screen size.

    Best regards,
    Dante

     
  • Davide Bucci

    Davide Bucci - 2014-07-11

    Dear Dante,
    I understand what you mean. I think a View would be a good thing even for bigger screens, to optimize the available space.

    BTW, I tried the app with a Samsung S5, which has a full HD screen in a 5" screen. Quite impressive, the DialogParameters shows fine, but a lot of other elements are way too small. For example, the grid has points so small that they are practically invisible. Handles and crosses are too small also. I will try to work on that in the future, letting chose some external parameters in the appropriate classes, or detecting automatically the screen resolution and change the size in pixels accordingly.

    Cheers,

    D.

     
  • Davide Bucci

    Davide Bucci - 2014-07-21

    Dear Dante,
    I saw your commit and now the app when closed and reopened retrieves the last drawing being edited. This evening, I was participating to this discussion (in italian):

    https://groups.google.com/forum/#!topic/it.hobby.elettronica/CiZuWAg5OJc

    Do you know where the drawing files are saved by the app? I think it is on data/fidocadj, but I might be wrong. BTW, it seems difficult to retrieve them with the usual file transfer utilities.

    Cheers,

    D.

    P.S. I tried to make a little bit easier to use the fingers for editing the graphic elements. Now the app should be fit for high resolution devices at least for this point of view.

     
  • cronos80

    cronos80 - 2014-07-23

    Good Morning all,
    I wrote a very simple file explorer. As I read on electroyou forum, it is something that could be useful to you. Attached the file with the source code.
    Please feel free to ask any explanation.
    See you

     
  • Dante Loi

    Dante Loi - 2014-07-23

    Dear cronos80,
    I checked, your code and I like that. It's simple and readable, I could adapt it, very easily...

    Dante

     
<< < 1 2 3 4 5 6 > >> (Page 4 of 6)

Anonymous
Anonymous

Cancel  Add attachments