What I'm mostly interested is the library refactoring (making the shared code a separate library), followed by Gradle files and AS project files for each, followed by Maven packages (or equivalent). It is important to keep code compatibility with existing apps, so a package name change in this case would do more harm than good, unless there is some solid technical reason to do that. As far as the Log abstraction, I think it is important that the shared code (one that goes into IOIOLibCore in your case) is agnostic to both Android and PC, so the platform-specific code needs to go into the platform-specific libraries as opposed to including code that supports two platforms in the generic codebase. The way IOIOConnections are registered currently is an example of a similar pattern, but there are simpler ways to achieve that when we're talking about 1 class per platform (i.e. the Log class can have a static instance that it loads dynamically, with a fixed classname). Hope this makes sense.
On Wed, Jan 21, 2015 at 7:49 AM, Thanos Fisherman <[email protected]> wrote: > Maybe I can do as you suggested for the API change I'll just leave > BaseIOIOLooper class and IOIOLooper interface untouched and implement > a BaseIOIOLooperAlt of my own but either way let me know > > > Hey Ytai, >> I'm afraid the existing apps will break imports anyway cause I renamed >> all the Core packages from ioio.lib to ioio.corelib in order to make more >> clear to the user where each import is coming from. But this can be easily >> fixed with a few clicks plus I can still include the old IOIOLib directory >> in the repository. Let me know >> >> Regarding the API change I can simply overload the methods in IOIOLooper >> e.g >> >> public abstract setup() >> public abstract setup(IOIO ioio) >> >> So the user can choose to override whatever method he wants. And btw You >> already doing that with incompatible(); and incompatible(IOIO ioio); methods >> >> One more thing to let you know is that in order for my unified logger >> class to work correctly, I had to move the static blocks from >> IOIOAndroidApplicationHelper >> and IOIOPcApplicationHelper into their constructors. Then I tested the >> whole thing and it worked correctly. Do you think this is ok? >> >> >> >> Thanos, >>> Your proposed library structure makes a lot of sense. Would you be >>> willing to: >>> >>> 1. Squash these changes into a single commit and send a pull-request. >>> 2. Once merged, follow up on updating the relevant wiki pages. >>> >>> Regarding the API change of the looper, there is a problem with the >>> approach you took, which is breaking compatibility with existing apps. In >>> other words, if users upgrade the library, their existing code will break. >>> Since all that's required by the framework is a valid implementation of >>> IOIOLooper, then instead of modifying BaseIOIOLooper, you can add something >>> like BaseIOIOLooperAlt with whatever contract you prefer for your subclass, >>> where BaseIOIOLooperAlt either extends BaseIOIOLooper or not. Then, users >>> would be able to use one or the other. Personally, I don't see much added >>> value in this approach. Having direct access to the ioio_ member is often >>> useful in that it saves having to pass it around to utility methods, when >>> the logic becomes too complicated to fit in loop(). >>> >>> Thanks for doing that! >>> >>> On Tue, Jan 20, 2015 at 7:54 AM, Thanos Fisherman <[email protected]> >>> wrote: >>> >>>> Thats great to hear :) Eventually I will try to write some gradle stuff >>>> and make the libraries ready to be pussed to maven central (unless someone >>>> else does it first). Cause it's really handy to just use those libs in your >>>> projects with a few lines of code and let gradle do all the dirty job >>>> instead of including them by hand in android studio and make your project >>>> "polluted" with all those library projects >>>> >>>> Hi Thanos, >>>>> >>>>> This is almost exactly what I did when trying to get Android Studio to >>>>> work, so I can validate that these changes make sense to more than just >>>>> you. :) >>>>> >>>>> Regards, >>>>> Mark. >>>>> >>>>> On Tue Jan 20 2015 at 7:29:34 AM Thanos Fisherman <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello ioioers I've made a few refactorings to ioio libs (At Software >>>>>> directory) Hopefully trying to make them more intuitive (to me) >>>>>> >>>>>> BUT First Let me explain what I did. >>>>>> It took me a while to realize I had to copy the ioio libs from >>>>>> /IOIOLib/src/ioio/lib to either /IOIOLib/target/android or >>>>>> /IOIOLib/target/pc >>>>>> Then I realized they were linked via src_commons but I didn't quite >>>>>> like the project structure. >>>>>> So I moved src_commons to a seperate java project IOIOCoreLib so that >>>>>> both android and desktop backends can extend from it. >>>>>> >>>>>> I also made a unified Logger class that can be used across all >>>>>> subsystems. When on android it will print on logcat and When on desktop >>>>>> it >>>>>> will print on console using println >>>>>> so now I think the project structure is more organized and ready to >>>>>> be ported to android studio later on. So That's pretty much how the >>>>>> project >>>>>> structure is: >>>>>> >>>>>> >>>>>> IOIOCoreLib >>>>>> / \ >>>>>> / \ >>>>>> IOIOLibPC IOIOLibAndroid >>>>>> / | \ >>>>>> / | \ >>>>>> / | \ >>>>>> / | >>>>>> \ >>>>>> IOIOLIbAccessory IOIOLibBT IOIOLibDevice >>>>>> >>>>>> >>>>>> I've also removed the ioio_ protected field and put it as an argument >>>>>> in ioio event methods. So now the BaseIOIOLooper methods look like this: >>>>>> >>>>>> public void setup(IOIO ioio) throws ConnectionLostException, >>>>>> InterruptedException {} >>>>>> >>>>>> @Override >>>>>> public void loop(IOIO ioio) throws ConnectionLostException, >>>>>> InterruptedException {} >>>>>> >>>>>> @Override >>>>>> public void disconnected(IOIO ioio) {} >>>>>> >>>>>> >>>>>> I updated the HelloIOIO and HelloIOIOSwing examples so that you can >>>>>> check them out. You can find the changes here >>>>>> <https://github.com/ThanosFisherman/ioio.git> >>>>>> I just hope it makes sense to you as much as it makes to me >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ioio-users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ioio-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/ioio-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
