GSoC Android proposal

[John Ralls]

On Apr 6, 2012, at 4:58 AM, Muslim Chochlov wrote:

> Hi,
> 
> First of all, I have no idea how or why this conversation hit the public
> list (I really hope John can explain that).
> Not only it discloses private information on participants applying to
> GnuCash and Gnome as well, but also violates GSoC program rules. Apart of
> that
> it makes me and I guess students feel quite uncomfortable.
> I really hope this was done by a mistake and unintentionally.
> 


I shouldn't have included Muslim's rather frank evaluation of  Ngewi's proposal vs. the other proposals already submitted to Gnome, and I apologize for exposing that to the community.

That said, the discussion with prospective students about the scope of their projects needs to involve the whole Gnucash developer community, just as it did last year. Furthermore, one of Gnome's requirements as an Umbrella organization is that the prospective student demonstrate prior involvement with the project he (or she) wants to work for, and it will be a lot easier for us to get a slot if we try to play by their rules. There's no requirement that the contribution be related to the student's proposal -- but Ngewi, if you don't know C or Scheme well enough to fix a bug, we need to figure out something else that you can do. The more folks involved in brainstorming that, the better.


> Hello,
>> correct me if I am wrong, but if I understood the goal of the Android app
>> well, then it was such that the transaction/expense history would be
>> recorded on the device, and then imported to the desktop app, and not the
>> other way around.
>> 
> 
> This is absolutely true and that's the primary goal of the application. The
> thing that I was talking about and which confused John is
> import-export module in the source code of GnuCash.
> So stressing this one more time - application should allow user to:
> - entry data
> - store data
> - export data

OK. I said "if [the] app needs to get information from Gnucash". If it doesn't, then no worry there. However, see Hendrik Boom's critique of QIF in "GnuCash for Symbian" on Wednesday. That needs to be hashed out pretty soon. Perhaps a CSV format, which wouldn't need to conform to any standard (but would prevent the app from working with anything but Gnucash) is a workable solution. 

> 
>> As for the coding contribution, I also don't see any modules in the desktop
>> counterpart which are relevant to the Android application (again please
>> correct me if I'm wrong).
>> It should be noted that almost two weeks of the application period were
>> lost by those who were applying to GNUcash before GNOME accepted to serve
>> as an Umbrella org.
>> 
>> 
> Well, as Marina said this is one of the Gnome requirements that all
> proposals would have a link
> to code contribution. And if I understand her correctly you have a time
> until 20th of April to come up with
> a code contribution, that is you can later add a link in a comment to your
> proposal. Two weeks should be more
> than enough to fix a bug, write a test or do small refactoring.
> Most relevant modules would be src/import-export or src/libqof. Maybe
> Christian or John could help with identifying a thing to be fixed.

Or Derek, or Phil, or Mike... that's the reason I moved this discussion to the devel list, but it depends on Ngewi's skills with C or Scheme. Ngewi, are you fluent in either?

> 
>> @Muslim, I would be interested in knowing areas where your expectations
>> were not met and how the application can be improved (would it be in
>> technical detail, UI wireframing, or something else?). Thanks.
>> 
>> 
> I'm not going to talk about my expectations or evaluate your work, as again
> this is against GSoC rules.

No, making your expectations clear isn't against GSoC rules, nor is coaching prospects to get the best possible proposals. Muslim, you benefitted from a long discussion here in gnucash-devel before you even submitted your proposal last year. Why should it be any different this year?

> Instead I went through
> your proposal and here are some notes that could help you.
> 
> * You did come up with a schedule - that's a good thing and that was what
> your initial draft was definitely lacking.
> * Mockups are very good.
> * "How do you plan to achieve completion of your project?" - still empty.
> If it is in the template I would suggest it better be filled.
> * Now you write " Android application for Android API level 7 and above".
> Are you going to target 7+ platforms and support all of them? If yes then
> you should dedicate some time for that. Otherwise think of skipping this.
> * OpenIntents - what are you going to use them for? Is there something that
> you cannot do with standard Android intent mechanism.
> * "Integration of mobile application with desktop GNUcash" - what do you
> actually mean by that?
> * "Implementation of QIF export format" - you can describe of document a
> format not implement it. Are you talking about exporting feature here?

Ngewi, if you're not fluent in C or Scheme, an initial implementation of a QIF output module with some tests to show that it works might do for a contribution. You could put it on Github and put a link to it, and then Muslim and I would be able to tell the Gnome admins that its close enough given the scope of the proposal and your skills.

> * "Application passcode lock" - ?
> 
> Overall, a clear schedule is very important to successfully accomplish the
> project. Right now it looks more like a spaghetti. For instance, for the
> midterm you are going to present "standalone Android app for expense
> tracking", but add exporting mechanism only after midterm. Now putting
> yourself in a user place - how useful would you find an application that is
> only capable of storing data to the dark corners of your flash drive?
> Again, why would I need fancy widget on the desktop if my application
> doesn't do the most important task.

Regards,
John Ralls