I need to use geolocation to Android (using Monodroid). And I'm left with two problems.
The first: Should I explicitly warn the user (based on GPS-coordinate
(as in windows phone)
The second (more complicated): I followed this Localisation
sample but still has no lastKnownLocation. Is it because of
the emulator?
I'm not sure what you're asking in the first part of the question. Should you warn the user about what, your use of their location? I'd say that depends on how heavily you're using it, but at the very least they would see that you're requesting the location permission(s) when installing your app.
For the second question, take a look at this question/answer from a few days ago. In short, GetLastKnownLocation() can return null if the provider has never received any location updates.
Edit:
To answer your question in the comments, there are several ways to mock location data in the emulator. This page in the Android documentation walks through how to do it.
Related
I have a dataset of ~300 electoral districts (~10MB - 45MB depending on the file format - GML/KML/SHAPE/JSON). I'm hoping to build a mobile app (iOS/Android/Windows Phone) that will determine which electoral district a user is in based on their current lat/lon.
My original plan was to set up an Azure webservice and use SQL Server or DocumentDB's spatial functionality to provide the answer. But the electoral districts are fairly static, so if I can do this on the device it might be better.
I'm thinking I'll likely use Xamarin.Forms to build my app since the UI doesn't need to be that complex (I don't need to draw maps or electoral districts).
I see that EF6 seems to have spatial functionality that would work, but I'm finding conflicting info about whether or not that will work with Xamarin.Forms, or if the performance will be reasonable.
What's the best (fastest/simplest) library/class I can use to determine the electoral district locally in a Xamarin.Forms app?
I wasn't able to find a library/class, but it seems like I can code a solution myself with little effort. I found this link: http://www.codeproject.com/Tips/84226/Is-a-Point-inside-a-Polygon . I didn't quite understand it the first time I looked at it, but now it makes sense.
My plan is to store my electoral district (polygons) in SQLite locally. But, I'll also include 4 columns for min/max lat/lon of each polygon. That gives me the minimum bounding rectangle for each polygon, and will serve as a primitive spatial index of sorts to quickly identify a small subset of possible electoral districts. From there I can use the algorithm found on CodeProject to confirm which electoral district is the correct one.
Im building a small winforms app using: ayende rhino licensing. The licensing is working fine, I can create licences and distribute them as I choose.
The problem is, How do I make each license work on just one machine? I know there is a class in ayende's project called LicensingService which I believe does something like what I'm trying to do, but I just cant figure it out. I've done quite a bit of searching and couldnt really find any tutorials except this one.
Maybe someone has implemented this, or has some tips on how I could accomplish this? I do have access to a webserver, if that helps.
Any help is much appreciated, as always.
Depends how annoying you want to make it for your users to be honest. You could implement a HWID (see How to fast get Hardware-ID in C#? on how to generate them) which will be unique from system to system, then have your program check if the HWID matches the ID found to the place you store them on-line (usually by using a database).
Needless to say, this will make your application require internet connection in order to run which might be a bit frustrating for your users.
Or you can merge the HWID with the serial and have your application do the same to verify if they match, but that would be easily cracked by the average cracker.
In the end of the day, .net isn't the best as far as security goes since you can easily get the source code and modify the assemblies as needed to patch certain protections. Keep that in mind when deciding what route you want to take to protect your software.
I do not know what exactly is a rhino licensing. To tackle your need generally there are two approaches.
Either give some randomly generated password to the client machine, and maintain a pool of passwords in your server. Each time a password is entered to register the application in a local machine, check if it was already registered elsewhere by connecting to your server via internet.
Or, what we do is, generate a code unique to that machine (perhaps a hash of some unique machine id, say mac id) and get the client sent it to you. You would then rehash the code and send it back using some logic. Now when the client enters this code to his machine do the same thing: fetch the very machine id, do the same rehashing using the same some logicand check if it matches.
I cant think of anything else
Is there a way to determine what (and where) in my code is causing certain capabilities to be required?
When I run CapabilityDetection.exe against my bin folder it comes up with:
ID_CAP_MEDIALIB
ID_CAP_NETWORKING
ID_CAP_PHONEDIALER
ID_CAP_WEBBROWSERCOMPONENT
ID_CAP_IDENTITY_USER
ID_CAP_MEDIALIB indicates that you're accessing the media library somewhere, but I've seen this reported incorrectly a lot. ID_CAP_NETWORKING means you're accessing a data connection at some point, ID_CAP_PHONEDIALER means that you're making a phone call, ID_CAP_WEBBROWSERCOMPONENT means that you've go the WebBrowser control on at least one page. I don't think I've ever seen these reported in error. ID_CAP_IDENTITY_USER means that you're using the anonymous Windows Live ID for user identification, which is typically the case when you're using a third party analytics solution such as mtiks or Flurry.
There's a list of the various capabilities on MSDN. Generally speaking, if you don't think you're using a particular capability, take it out, and then check that your application still runs as expected.
I am relatively new to FB development, but I have managed to do what I wanted, which was to get a list of friends, and from each of them, get their work history. I accomplished this by using Facebook's own C# SDK, and using the Get method on each of my friends, basically doing: _fa.Get("/").
This worked perfectly up until a couple of days ago, where it suddenly stopped working, and now I no longer have the work history (and education for that matter) available to me in the JSONObject which is returned from the Get method. One other thing of note is that a couple of my friends who installed the app I am developing (as a means of testing), do return their work history, but other friends (who have not installed the app), and do have a work history open (which I can see if I look at their profile by browsing into it with my browser) do not return it in my Get call...
The obvious explanation is that FB changed something, and now applications can no longer access this information unless installed on a specific user profile (hence the odd behavior).
Has anyone else encountered the same thing? Am I doing something wrong?
Any help would be appreciated!
Many thanks,
As you said, the answer appears obvious and is probably some change in default privacy settings that have been rolled out. Note that Facebook has introduced a couple of new features this week, most notably the "places" stuff. Most likely work history is not shared anymore by default. You probably only had access because the work history was publicly visible anyway.
Update
Seems to me, the best places to check for changes is the developer blog and the developer roadmap.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Where do programs save their secret license or install related information? I notice that often times when you uninstall a program, clear out appdata references, check registries to make sure there is no residue of any relevant information.
If you reinstall the trial program again, it seems to know it was installed before. I'm not looking to find a way to crack trial programs but actually need to implement something similar and can't find any good information on how to do this.
Registry
online
file in folder Windows with system like name
I even seen apps that hacked unused OS variables to store custom data in registry.
But the simplest method is to register a handler for a custom unused file type like .sof (if that is there, it was installed before) Edit 1 You have to register the handle to open a known executable on the system, not to your app. Because cleaners will detect if points to a no longer existing app location. As for storing additional params like date of trial expiry you can include them in the path as a param, like: cmd.exe -o 2010-02-09
I have handled this in two ways. First, in windows apps, I put in an encrypted Registry entry which is not in a standard location so that it is not easily found. This is a good solution if you don't mind people who either a) reformat often which removes all registry entries or b) use your software on a virtual machine which can be quickly reverted to a pre-trial state (and thus your trail can be used again quickly).
The better alternative is to have an online registry component which catches the MAC address of the machine which the trial is loaded on. Whenever the trial is reloaded, the software checks against a web service to see if the MAC address has been seen before. The only way around this is again using a Virtual Machine with the ability to change the MAC address. However, if you have a user that goes to this extreme, they'll use your trial regardless.
Probably the most foolproof way of licensing (when done right) is through something the user physically has - some kind of hardware dongle.
very hard to copy/duplicate
not dependent on network access
tamper-resistant (compared to software)
user-friendly (when working correctly)
licence count enforcement (can't easily plug 1 dongle into 10 machines at once)
Of course, it has also numerous disadvantages:
expensive to produce
hard to repair/replace
actually requires you to communicate with the dongle in a cryptographically secure way - any kind of if(dongle_ok()) { do_stuff() } is an invitation for crackers to patch that over to if (1) { do_stuff() }...
...which will require special drivers...
...maybe even a special interface (I still have a LPT dongle, but no LPT ports; USB<->LPT sucks)
don't even think of hooking it up to a virtual machine (although peripheral support is better in VMs nowadays)
support hell (is it connected? is it not broken? is the driver not broken? are the signatures/keys right and unexpired?)
fragile, esp. if it sticks out of the computer and/or has destructive anti-tamper mechanisms
may break communication with other peripherals (esp. those "pass-through" things were notorious for this)
For most programs, the disadvantages far outweigh the advantages; however, if you're making expensive, complex software (think "production plant control"), your clients are rather cavalier about licensing (in other words, "would buy a single copy (crack it if necessary) and run it on 50 machines if they could get away with it"), and lawsuits are impractical (take too long, you don't have much evidence, uncertain outcome), this may be useful. (I didn't say simple, did I?)
They save it wherever they can, secret files, secret registry keys. There are commercial products that offer this kind of protection, like asprotect, armadillo, etc.
Some products will utilize ADS (Alternate Data Streams) and hide the data in various places.
Others will leave behind "rootkits" cough SONY.
Also some will create special registry entries that cannot be delete easily, such as entries with NULLs in the name.
It sometimes depends on how scrupulous the developer is.
Could also try making the file or folder hidden - most users don't know to reveal hidden files and folders. Then you can put it anywhere really. C:/WINDOWS is sometimes a good choice because of that silly window that shows up when you click it for the first time that says "DANGER! DO NOT EDIT ANYTHING IN THIS FOLDER OR YOUR OS WILL MESS UP!" This will hide most anything from the lay man, but let's face the facts, you're not hiding anything from anyone that is active on stack overflow. :)