New to AdMob and trying to understand compliance as it relates to providing and deleting collected user data to a user upon request from purely programming standpoint.
In my research, it appears that there is an API for the user to at least delete the data. https://developers.google.com/analytics/devguides/config/userdeletion/v3/ being the most helpful so far though not specifically particularly helpful in code examples. This would probably be accomplished either by the developer using the client ID manually or via the developer's app -> user deletion API.
Assuming one of the two approaches is the proper way the industry is currently handling this, how is this typically handled in Swift (ideally via SwiftUI not UIKit but I can follow along either way)? Please note I am not asking how to set up AdMob in general, or how to use UMP to provide GDPR consent, or what anything related to legal/compliance beyond programming.
If there is some other, more preferred option, please let me know that as well.
Thus far I have researched the differences in client ID and user ID from an end user perspective. Code-wise, I am unsure where to start until understanding which approach to take as dictated by the answers above. I have also looked into exposing the client ID vs various items that might be used as a generic device ID but am unsure how best to obtain this as well.
Thanks!
I'm admittedly unsure whether this post falls within the scope of acceptable SO questions. If not, please advise whether I might be able to adjust it to fit or if perhaps there might be a more appropriate site for it.
I'm a WinForms guy, but I've got a new project where I'm going to be making web service calls for a Point of Sale system. I've read about how CRUD operations are handled in RESTful environments where GET/PUT/POST/etc represent their respective CRUD counterpart. However I've just started working on a project where I need to submit my requirements to a developer who'll be developing a web api for me to use but he tells me that this isn't how the big boys do it.
Instead of making web requests to create a transaction followed by requests to add items to the transaction in the object based approach I'm accustomed to, I will instead use a service based approach to just make a 'prepare' checkout call in order to see the subtotal, tax, total, etc. for the transaction with the items I currently have on it. Then when I'm ready to actually process the transaction I'll make a call to 'complete' checkout.
I quoted a couple words above because I'm curious whether these are common terms that everyone uses or just ones that he happened to choose to explain the process to me. And my question is, where might I go to get up to speed on the way the 'big boys' like Google and Amazon design their APIs? I'm not the one implementing the API, but there seems to be a little bit of an impedance mismatch in regard to how I'm trying to communicate what I need and the way the developer is expecting to hear my requirements.
Not sure wrt the specifics of your application though your general understanding seems ik. There are always corner cases that test the born though.
I would heed that you listen to your dev team on how things should be imolemented and just provide the "what's" (requirements). They should be trusted to know best practice and your company's own interpretation and standards (right or wrong). If they don't give you your requirement (ease-of-use or can't be easily reusable with expanded requirements) then you can review why with an architect or dev mgr.
However, if you are interested and want to debate and perhaps understand, check out Atlassian's best practice here: https://developer.atlassian.com/plugins/servlet/mobile#content/view/4915226.
FYI: Atlassian make really leading dev tools in use in v.large companies. Note also that this best-practices is as a part of refactoring meaning they've been through the mill and know what worked and what hasn't).
FYI2 (edit): Reading between the lines of your question, I think your dev is basically instructing you specifically on how transactions are managed within ReST. That is, you don't typically begin, add, end. Instead, everything that is transactional is rolled within a transaction wrapper and POSTed to the server as a single transaction.
My company is looking to develop an iOS application which would need to make use of private APIs to function - in fact use of such APIs is the entire basis of the program (I'm purposely not revealing details for business reasons).
My question is, is there any chance that if we explained the situation, that Apple would allow an exception for our app to be approved even when using these private APIs? I believe we have a very legitimate reason to request an exception for the functionality we're looking for, so I'd just like some examples of any exceptions that have been made to the private APIs rule with details so that we can have a better idea of what might be expected from Apple. Thanks.
I'll be honest with you: no. If you're looking to put this on the app store, no.
You may wonder how I know this with such certainty: I've worked with carriers that carry the iPhone, and I've worked with very large companies with whom Apple has working relationships (ie, you can actually talk to someone fairly senior at Apple). If Apple won't let carriers use private APIs, they not going to let you do it either. One 'legitimate' private API use might be to put recent call information into a carrier provided account app. Could be pretty useful, right? And the carrier already has this information, so no problem? No. It's a big problem. Apple just won't allow it. You have to get it from elsewhere (ie, via the carrier's own database).
There are no exceptions, and currently apps get statically analysed immediately after submission. If you call a private API your app will almost certainly be instantly rejected automatically by the static analyzer. It won't even go through manual review.
If you're looking to distribute on the app store, there are literally no exceptions now that code gets statically analyzed.
Put it another way: if Apple made an exception for your app they'd have to make an exception for every app. And then your unique selling point wouldn't be so unique any more.
Sorry I can't give you a more positive answer, but I speak from experience!
Its entirely possible, but extremely unlikely. they made an exception for UIGetScreenImage(); but that was because there was a very large number of developers who had filed radars for it.
I would suggest you file high quality radars for enhancement, explaining what you want and why. also maybe consider using a DTS to find out if there is an alternative way, or if they are able to get authorisation for it.
This question doesn't pertain to building the app itself, because that will be handled by a programming company. My question pertains to the EFT protocol itself. Is there a general protocol for programmers to follow to securely complete an EFT transaction, or do I have to build a direct relationship with each banking institution to get this service going?
I have tried to research this topic but I seriously don't know where to start, or what to search for on Google. The project is at its research phase. Any insight is greatly appreciated.
I've been working in the Financial Industry for many years and I am not aware of a standard EFT protocol. There are established formats that the data must conform to for transmission from institution to institution. With that being said, every institution has slight differences that they require for their back end systems.
My advice is to build a relationship with a EFT clearing house. This way you will only have to write an interface to the clearing house and let them deal with the actual EFT transfer.
Depending on the nature of EFT app you are developing, you might be interested in knowing more about ISO8583, IFX as well as FIX protocols.
ISO8583 is used by a huge percentage of card based transactions, e.g., those occurring on ATM's or via VISA, Mastercard, etc.
IFX is a relatively newer standard. As far as I know the adaption has been slow.
FIX is more suitable to commodity trading (as in stock exchanges).
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 8 years ago.
Improve this question
My company is trying to pass a policy forbidding distribution of any application (even free) in any appstore for all developers.
Their reasoning is that "outside work activities create a conflict of interest". They don't want that "you use your spare time to work on your app, and once it takes off you quit your job" (quoting the Head of Development).
A few developers (myself included) have already said it was an abusive, pointless and most of all counter-productive policy (developers will actually be demotivated to work here under such control and to be denied of the freedom to distribute their project).
Personally, I think it is actually in the interest of the company to promote side projects (even commercial activities, if there is no conflict).
I'm also curious, is that common practice?
Needless to say, this is horribly, horribly stupid on so many levels... It may be worth trying to find out whether it's even legal in your jurisdiction.
Anyway and apart from that, if you can, find colleagues who feel the same, and take a stand against it. Try to explain to the management that this is a stupid decision for the company as well. Don't sign anything: A policy like that would probably have to be amended to your work contract to be binding. Chances are, the risk of losing good employees over this outweighs the security they think they get from it.
If there's really nothing that can be done, and you are very unhappy with this (I would be), consider looking for a new job.
As an afterthought, if the practice of limiting your employees' rights to this extent is clearly illegal in your jurisdiction, it could be that simply making them aware of this might stop this without any further trouble.
All companies for which I have worked allowed outside work provided:
no company resources were used (this includes time)
the product of that effort did not directly conflict with the company's interest
the product was not based off of work or specific knowledge gained while working for the company
Typically, companies have a clause in your employment agreement that states that you will inform them when you begin work on outside projects and inform them of the nature so they can approve/deny. In such cases, you want to get that approval in writing.
In your case, this is a pretty difficult situation if this was part of your employment agreement. Even if it isn't, they can fire you for it if your employment is at-will and they find out. Unfortunately, in your situation, you seem to have one of four options:
Convince management that they are being unreasonable.
Fly under the radar and hope you don't get caught.
Find a new job.
Quit and just work on the apps full-time.
If your job is to put out apps in an appstore, though, there's really no way to argue that your outside development of apps for the same appstore isn't a conflict of interest in some respect. If I had to guess, I'd say that either this is the case or you're working for a development manager that doesn't understand the mindset of developers and how they like to tinker and learn outside of work.
While this example sounds a little draconian, it is not uncommon for companies to have some kind of policy regarding outside work. However, this is typically to protect the company from your mistakes rather than to protect them from your departure. If they're that concerned about employees leaving, they should go out of their way to make it the sort of place you would want to stay.
EDIT: I just found this today on a completely unrelated blog, but it totally rings true to this discussion. It's about 11 minutes long, but very entertaining and makes you think too. http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_embedded The TL;DR (TL;DW?): Once you get outside the realm of purely physical tasks, organizations that assume you are motivated by money, hands-on direction, etc. will not accomplish their goals nearly as easily as those that assume you are motivated by desires for autonomy (self-direction, self-management), mastery (getting better at doing something) and contribution to something bigger than yourself.
I believe there was a similar pointless rule when I was under the corporate yoke. I think these rules are pointless, backward and wrong. Instead of keeping their developers management pushes them to look for new managment, well, at least the passionate and talented ones.
Unless your employment contract says otherwise, what you develop in your own time belongs to you.
If they are in the business of writing apps for the appstore, then they might have a non-compete argument against you.
If they allow other types of development projects, it is difficult to see the argument as valid.
Depends on the app and the company.
If you're working for an Android app developer, I'd see why they might not like it. 8)
If it competes directly with what your company produces I can see why they'd prohibit it.
I would consult a lawyer to see just how binding such an agreement would be if you were forced to sign it.
If it's really that odious, your only recourse is to find another employer.
Check your local labor laws. In California, this kind of thing is blatantly illegal.
The policy enumerated by Shaun is reasonable, and something very similar has been in place at most of my previous employers. The one place that tried something like this was quickly pointed at the statute by knowledgable developers, and the "policy" quietly went away.
The answer is in your contract of employment.
But if your job is as a computer programmer, you're almost guaranteed to have something in your employment contract stating that any software you write either in work or outside of work is owned by the company.
If you get written permission from HR and your manager, then if you were to make millions from you out of hours projects, then it would be more difficult for your employer to just take ALL those millions off of you.