<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Tml I dunno if you want students to use my existing android project / app, please let me know if thats not the case.</div><div><br></div><div>If you look in the android/experimental/eagles051387 that is where my basic project is, that you are more then welcome to use or copy the project into another directory under your name in the same experimental directory</div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>Regards</div><div>Jonathan Aquilina</div></span> </div> <br><div><div>On May 8, 2012, at 10:19 PM, Andrzej J. R. Hunt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>just a few small (code) organisational issues -- I'm not entirely sure where it's best to place the code: there are going to be 3 components:<br>- The common code (thrift definition)<br>- The server component<br>- The android app<br><br>I thought it might be most appropriate to create a new folder in the main libo directory e.g. "impressremote", which will contain the thrift definitions and android app (with space to add more apps for other smartphones).<br><br> The server componentI think is best kept in sd/source/ui/remotecontrol for the gui part, the actual server code could be there or in sd/source/core/remotecontrol.<br><br>Since thrift isn't available as a standard package on most distros (and windows) would it be appropriate to add downloading and building of thrift to the makefiles? Or should I change the choice of RPC to use something with simpler dependencies (thrift seems to be most suitable from what I've been able to determine, although XML- or JSON-RPC wouldn't really be a problem in terms of efficiency, what is more of an issue is making these work bidirectionally -- another alternative is scrapping RPC and implementing a custom messaging protocol, but this would be less flexible for the case that someone wants to extend things in the future -- in gmote they have a custom packet implemented as a class for every command, with this object being serialised and then sent, and deserialised at the other end -- although this wouldn't work in our case since the server is in C++, and the client in an arbitrary language).<br><br>Cheers,<br>Andrzej<br><br><br>_______________________________________________<br>LibreOffice mailing list<br><a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br>http://lists.freedesktop.org/mailman/listinfo/libreoffice<br></div></blockquote></div><br></body></html>