GSoC Android proposal

[Ngewi Fet]

Hi John,
I have done some C/C++ programming, but it has been a while since I did
coding in the language.
I have checked out out the Gnucash code and I am looking at the bug tracker
too.
Hopefully I will be able to make a contribution soon. Else, I may have to
do the QIF module as you suggest.

Cheers,
Ngewi

On Fri, Apr 6, 2012 at 16:49, John Ralls <jralls at ceridwen.us> wrote:

>
> 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
>
>