GSoC Android proposal

Mon Apr 9 06:36:00 EDT 2012

Hi,
Thanks for the input. Will keep it in mind next time.
After the discussion with John, I was going to go for the QIF module.
But I can work instead on the OFX module and have some code to show by
tomorrow.
After googling a bit, I also feel OFX may be a better choice.

Cheers,
Ngewi

On Sun, Apr 8, 2012 at 21:31, Muslim Chochlov <muslim.chochlov at gmail.com>wrote:

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