GSoC Android proposal

Sun Apr 8 15:31:17 EDT 2012

Hi,

As for the part  "How do you plan to achieve completion of your project?", I
> assumed that that was the part where the proposal was to be entered.
> Because the next sentence just seems to add detail to the question "It
> really helps to see a schedule with dates and important
> milestones/deliveries (preferably in two weeks increments)."
>
> In this part you could go more into detail on which technologies you would
use, what would
be your application's architecture etc. It should prove that your are
familiar with the tools you are
going to use and actually understand what you will be doing.

> The application passcode lock is to enable one to be able to lock the
> application with the passcode, so that if someone borrows a device
> temporarily they do not have to see all your transactions. But maybe this
> is not so necessary.
>
> It is definitely a nice thing to have, but it should be left behind until
the tasks with a higher priority are done.
You should focus on implementing storage, ui, and export functionality.
Things like passcode locker, multiplatform support and similar should be
shifted towards
the end of your coding period. So that they don't stand in the way of your
main tasks. I checked your
projects on the github and it seems you have good Android programming
skills. But again I would suggest you to start development
targeting the most recent platform sdk (or whichever version you prefer)
unless you are quite confident you can do it multiplatform from the
beginning.

Also take a look at the parallel thread about Symbian mobile application,
which is basically a twin brother of your project.
Christian suggests using OFX format instead of QIF, because it will cause
less trouble when importing into desktop app.
Correct me if I'm wrong Christian.
If so, I would go for OFX format so that we don't get into trouble later.

What are you working on now (if working)? The deadlines are approaching and
it is
essential to have some code to show to Gnome. If you have a piece of code,
even one line - show it.

Cheers,
Muslim Chochlov

> On Fri, Apr 6, 2012 at 13:58, Muslim Chochlov <muslim.chochlov at gmail.com
> >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.
> >
> > 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
> >
> >
> >> 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.
> >
> >
> >> @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. 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?
> > * "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.
> >
> > Cheers,
> > Muslim Chochlov
> >
> >  On Fri, Apr 6, 2012 at 04:52, David Reiser <dbreiser at earthlink.net>
> >> wrote:
> >>
> >> >
> >> > On Apr 5, 2012, at 5:02 PM, John Ralls wrote:
> >> >
> >> > >
> >> > > On Apr 4, 2012, at 8:00 AM, Muslim Chochlov wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> The good news are that one student (Ngewi Fet) has submitted his
> >> > proposal for mobile application.
> >> > >> And AFAIK another one (Atul) is going to submit as well.
> >> > >> The bad news are that Ngewi's proposal doesn't seem to make it
> >> through.
> >> > Apart from basic information about the application
> >> > >> he is going to develop there is nothing that can make him stand out
> >> of
> >> > the crowd of other participants. I don't know how many slots Gnome
> will
> >> > receive
> >> > >> but they already have 5-6 very strong proposals and it would be
> >> > extremely hard for Ngewi to compete with them. Currently I would rate
> >> him
> >> > 2-3 out of 5 and I have to admit I expected more from him.
> >> > >> You could find his application here [1]
> >> > >>
> >> > >> [1]
> >> >
> >>
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/ngewif/1
> >> > >
> >> > >
> >> > > Muslim,
> >> > >
> >> > > You wrote on your comment to Ngewi's proposal:
> >> > >> Also it is very important that you understand how import/export in
> >> > GnuCash works and QIF file format. Because this is the main purpose of
> >> the
> >> > GnuCash mobile application.
> >> > >
> >> > > You know that there is no export from Gnucash, right? The export
> menu
> >> > items write a chart of accounts to an empty Gnucash file or, on
> reports,
> >> > write out the HTML from the report to file.
> >> >
> >> > Trunk has a CSV transaction export. I haven't tried a round trip yet,
> >> but
> >> > the transactions seem to be there in the export file. And you do have
> >> to do
> >> > one category at a time (Income/expense/asset/liability).
> >> > >
> >> > > If Ngewi's (or Atul's, if he gets around to writing a proposal) app
> is
> >> > to get information from Gnucash I think that the only option is for it
> >> to
> >> > parse the XML data file.
> >> > >
> >> > > On a related note, Marina Zhurakhinskaya (one of the Gnome admins)
> is
> >> > commenting on all proposals that don't have a pointer to an existing
> >> > contribution. Do either Atul or Ngewi have the C experience to knock
> >> out a
> >> > couple of bugs? It's not really germane to their proposals, because
> >> those
> >> > will be written in Java, but it seems to be a Gnome GSoC requirement.
> >> > >
> >> > > Regards,
> >> > > John Ralls
> >> > >
> >> >
> >> > Dave
> >> > --
> >> > David Reiser
> >> > dbreiser at earthlink.net
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > gnucash-devel mailing list
> >> > gnucash-devel at gnucash.org
> >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >> >
> >> _______________________________________________
> >> gnucash-devel mailing list
> >> gnucash-devel at gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> >
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>