Any update on the Maven? I have an app on Android Studio where I want to 
integrate the IOIO board.

Thanks

On Tuesday, March 10, 2015 at 12:07:09 AM UTC-5, Ytai wrote:
>
> Thanks, Mike!
> Re differentiating boards, on the USB level there are OS-specific 
> differences:
>
>    - On Windows the port assignment is pretty non-deterministic.
>    - On OSX, the device (file) name depends on which USB port it is 
>    connected to.
>    - On Linux, you can access by connection or serial number.
>
> So it doesn't seem like there's an easy way to secure a consistent name on 
> all OS. Also, currently there is no serial number programmed, but this is 
> solvable with some effort.
>
> An easy alternative for you is to either jumper some of the unused pins to 
> act as an ID (for example, decide that pins 45-46 on each board act as ID, 
> where on one both will be shorted to GND, on one only 45 and on one only 
> 46). You can even be clever and distinguish between "GND", "3V3" and 
> "un-connected" if you open each pin twice, once with a pull-up and once 
> with a pull-down. A similar alternative is to connect an external EEPROM 
> over I2C to each of your boards. Many EEPROMs have built in unique serial 
> numbers, and if not, you can use the EEPROM itself to write an ID.
>
> As far as how the software should be delivered: initially, the main use 
> case has been Android. The official way to distribute libraries was in 
> source + Eclipse project form. Sux, I know, but JARs aren't sufficient for 
> all the metadata. Now that Android has moved to AS / Gradle I'm very open 
> to moving. Maven is something that has been discussed as well and I'm very 
> interested in doing that. Essentially, the fewer number of steps for 
> setting up "Hello World" and the less boilerplate code, the better. Only 
> problem is that I'm not personally familiar with state-of-the-art ways of 
> doing these things. I've previously called out for people on the mailing 
> list to help out, but nobody stepped up (well, some did, who admitted to 
> not being too sure about how this "should" be done). If you think you know 
> how to do this right, please let me know. I'd like to discuss some details 
> with you before you spend any efforts, just to make sure we're on the same 
> page and that you're aware of all the relevant work-flows.
>
> Ytai
>
> On Mon, Mar 9, 2015 at 8:08 PM, Michael Grundvig <[email protected] 
> <javascript:>> wrote:
>
>> First off, thanks very much for creating a Java-powered IO board. For all 
>> my projects that need a lot of IO, I've ended up using the Phidgets 0/16/16 
>> board and while it works well, it's a whopping 100 bucks a board for just 
>> 32 digital IO pins. Sparkfun's site showed the IOIO OTG and I ordered it 
>> immediately and had it wired up and working in just a few minutes after it 
>> arrived. I think it will be perfect for my next few planned projects. 
>> Combine it with a Raspberry PI and you have a powerful Java-based system 
>> that is cheap enough to leave embedded in the project which is especially 
>> nice!
>>
>> Now, onto my question. My next project will need three IOIO boards and 
>> I'm trying to figure out the best way to address/sequence them. I see I get 
>> an "Object extra" on createIOIOLooper but after checking, it's just a 
>> string that says "COMx". As COM ports are assigned when things are plugged 
>> in and removed they are pretty fluid. This makes for a bit of a problem 
>> because when I move the display around I have to reconnect everything in a 
>> specific sequence as I can't ensure which IOIO board is which and their 
>> physical orientation is critical to the app working. In this specific 
>> project, I can get away with bringing one of the IO pins I'm not using low 
>> and check for it in code but that's a pretty sloppy solution. Is there a 
>> better way to physically identify a board rather than just the COM port? 
>> Ideally the API would expose some unique ID or allow us to assign an ID to 
>> a board. That would totally solve this problem.
>>
>> Next, I have a couple of suggestions that might lower the barrier of 
>> entry for us desktop users based on my initial experience. 
>>
>>    - Compiled jars - I was really surprised that I had to compile the 
>>    source for a project. It's been a long time that an open source API I 
>> used 
>>    didn't have already compiled jars. This isn't a big hurdle but it does 
>> make 
>>    it a bit of a hassle for new devs. It also makes it very unclear what 
>>    versions of the API code I have unless I set up a local repo for this and 
>>    such. Just not something I'm going to bother to do for a small project. 
>>    - Non-IDE specific tutorials - unfortunately the tutorials are based 
>>    around Eclipse. While that's obviously a popular IDE, it's really 
>> limiting 
>>    as many of us don't use Eclipse or are looking for actual details of the 
>>    API, not details on how to configure Eclipse. I would have been very 
>> happy 
>>    with a simple list of current jars to use and a quick HelloWorld snippet 
>> I 
>>    could cut and paste. The specific jars to use were the most unclear as 
>> they 
>>    are very nicely broken down into PC vs. Android and such but it's not 
>>    trivial to find which are needed in what context without some digging. 
>>    - What about using a build tool like Gradle? Obviously Google is 
>>    going this direction and it's a pretty superb tool all around (we use it 
>> on 
>>    a massive project at work with a huge number of dynamically version-ed 
>>    modules and its been rock solid). Sadly Eclipse has pretty mediocre 
>> support 
>>    for it (I'm not an Eclipse fan in general though, so I admit bias) but it 
>>    still works nicely and is completely environment agnostic. Even using it 
>>    purely command line is very easy with a Gradle wrapper setup. 
>>    - In the same vein, why not get the jars into the Central Maven repo? 
>>    That would make IOIO even easier to get started with as you just have a 
>> few 
>>    dependencies and let 'er rip. Overall, it just makes everything simpler.
>>
>>
>> Anyways, this project is great and I'm really excited to see a 
>> Java-language project take off. Is this group open to patches and 
>> enhancements to the Java api being submitted? I saw a few things I thought 
>> I could contribute if that's on interest. Thanks again for all the amazing 
>> work!
>>
>> -Mike
>>
>> -- 
>> 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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> 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.

Reply via email to