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 <[email protected]>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 <[email protected] >> >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 <[email protected]> >> >> 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 >> >> > [email protected] >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > gnucash-devel mailing list >> >> > [email protected] >> >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> > >> >> _______________________________________________ >> >> gnucash-devel mailing list >> >> [email protected] >> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> >> > >> > >> _______________________________________________ >> gnucash-devel mailing list >> [email protected] >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
