support for period (.) or punctuation in version #

[stevenolen]

When adding an application if I use 2.14.4 as my version number the page returns "error connecting to database." entering 2144 allows the application to be added. Could we support periods in the version number as versioning commonly uses decimal point revisions? alternately, could the version field be sanitized and any non-allowable characters be removed. another alternative could be to simply parse and tell the user that the problem is (as I had to guess when receiving that error message that the version number was the issue).

Thanks!

[jojenki]

This number must coordinate with the number on the APK, so we can't change that. However, this should probably be captured somewhere.

From my Android phone on T-Mobile. The first nationwide 4G network.

----- Reply message -----
From: "stevenolen" reply@reply.github.com
To: "John Jenkins" jojenki@cens.ucla.edu
Subject: [CENSUpdaterServer] support for period (.) or punctuation in version # (#5)
Date: Tue, Jul 24, 2012 3:42 pm

When adding an application if I use 2.14.4 as my version number the page returns "error connecting to database." entering 2144 allows the application to be added. Could we support periods in the version number as versioning commonly uses decimal point revisions? alternately, could the version field be sanitized and any non-allowable characters be removed. another alternative could be to simply parse and tell the user that the problem is (as I had to guess when receiving that error message that the version number was the issue).

Thanks!

---

Reply to this email directly or view it on GitHub:
#5

[stevenolen]

Then perhaps we could capture it and allow a version number to be
specified...so we can easily see what software version it is.
On Jul 24, 2012 2:55 PM, "John Jenkins" <
reply@reply.github.com>
wrote:

This number must coordinate with the number on the APK, so we can't change
that. However, this should probably be captured somewhere.

From my Android phone on T-Mobile. The first nationwide 4G network.

----- Reply message -----
From: "stevenolen" reply@reply.github.com
To: "John Jenkins" jojenki@cens.ucla.edu
Subject: [CENSUpdaterServer] support for period (.) or punctuation in
version # (#5)
Date: Tue, Jul 24, 2012 3:42 pm

When adding an application if I use 2.14.4 as my version number the page
returns "error connecting to database." entering 2144 allows the
application to be added. Could we support periods in the version number as
versioning commonly uses decimal point revisions? alternately, could the
version field be sanitized and any non-allowable characters be removed.
another alternative could be to simply parse and tell the user that the
problem is (as I had to guess when receiving that error message that the
version number was the issue).

Thanks!

---

Reply to this email directly or view it on GitHub:
#5

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[wirru]

You could also put it in the Description field as a temporary fix. Adding a new field at this point is a little difficult because it requires migrating the Django database to a new model (not that it can't be done, though).

On Jul 24, 2012, at 2:57 PM, stevenolen reply@reply.github.com wrote:

Then perhaps we could capture it and allow a version number to be
specified...so we can easily see what software version it is.
On Jul 24, 2012 2:55 PM, "John Jenkins" <
reply@reply.github.com>
wrote:

This number must coordinate with the number on the APK, so we can't change
that. However, this should probably be captured somewhere.

From my Android phone on T-Mobile. The first nationwide 4G network.

----- Reply message -----
From: "stevenolen" reply@reply.github.com
To: "John Jenkins" jojenki@cens.ucla.edu
Subject: [CENSUpdaterServer] support for period (.) or punctuation in
version # (#5)
Date: Tue, Jul 24, 2012 3:42 pm

When adding an application if I use 2.14.4 as my version number the page
returns "error connecting to database." entering 2144 allows the
application to be added. Could we support periods in the version number as
versioning commonly uses decimal point revisions? alternately, could the
version field be sanitized and any non-allowable characters be removed.
another alternative could be to simply parse and tell the user that the
problem is (as I had to guess when receiving that error message that the
version number was the issue).

Thanks!

---

Reply to this email directly or view it on GitHub:
#5

---

Reply to this email directly or view it on GitHub:
#5 (comment)

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[stevenolen]

Now that I'm thinking about it...I set the version number for a particular ohmage release as 2142 and it seems to be working fine...even though I'm sure that isn't the correct version number offered by the ohmage apks (usually 12060500 or something like that...)

What should the side effects of inputting an incorrect version number be?

[jojenki]

This is why I was pushing for apk validation. The ”problem” is that the application is slightly confused. It says the version must be 2000 or whatever, sees that its not installed, and updates it. Now out still thinks out should be 2000 but sees what it actually is, like 2012070100, and thinks, ” well its bigger so I will just assume its ok for now”. Does that make sense? Hard to explain on the phone.

From my Android phone on T-Mobile. The first nationwide 4G network.

----- Reply message -----
From: "stevenolen" reply@reply.github.com
To: "John Jenkins" jojenki@cens.ucla.edu
Subject: [CENSUpdaterServer] support for period (.) or punctuation in version # (#5)
Date: Tue, Jul 24, 2012 6:15 pm

Now that I'm thinking about it...I set the version number for a particular ohmage release as 2142 and it seems to be working fine...even though I'm sure that isn't the correct version number offered by the ohmage apks (usually 12060500 or something like that...)

What should the side effects of inputting an incorrect version number be?

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[stevenolen]

ah yes! I see the conundrum. I presume apk validation isn't a light task?

[jojenki]

On the server you mean? AAPT (part of the Android SDK) can get all of the badging information, so it's actually pretty simple.

[stevenolen]

Oh cool. Will do you have any time to look at this? I might want to take a
shot at the upload/scan apk stuff...would be a neat learning
experience...especially if you don't have time!
On Jul 24, 2012 6:12 PM, "John Jenkins" <
reply@reply.github.com>
wrote:

On the server you mean? AAPT (part of the Android SDK) can get all of the
badging information, so it's actually pretty simple.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[wirru]

I don't think I have the time to do that right now. Feel free to give it a shot :)

I was going to try doing it over the summer, but when I discussed with Hongsuda about it, we discovered that there were a bunch of related issues (i.e. where to store the uploaded .apk's on the server, etc.)

On Jul 24, 2012, at 6:14 PM, stevenolen reply@reply.github.com wrote:

Oh cool. Will do you have any time to look at this? I might want to take a
shot at the upload/scan apk stuff...would be a neat learning
experience...especially if you don't have time!
On Jul 24, 2012 6:12 PM, "John Jenkins" <
reply@reply.github.com>
wrote:

On the server you mean? AAPT (part of the Android SDK) can get all of the
badging information, so it's actually pretty simple.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[stevenolen]

OK. I looked into this briefly and decided it would be less a learning experience, and more of a "head bashing" experience as I have very little experience with python and no experience with django :). Here's what I found though that helps me a bunch (and I have no idea what I'm doing!) whenever this can be implemented:

http://stackoverflow.com/questions/5871730/need-a-minimal-django-file-upload-example

I think the answer to where to store the apks is suggested by that link as well, under uapp in a "apks" directory or similar. might as well make it all self-contained, I'd say.

For now I'll just write a bash script to curl new apps and send the correct parameters from lecs (where the apks are currently hosted).