ArcGIS Developer Foundation common mistakes
ArcGIS Developer Foundation · Understand the traps and how to avoid them.
Memorizing the names of the ArcGIS Maps SDKs (JavaScript, .NET, Java, Python, Qt, Swift, Kotlin) as a list without knowing which one to reach for given a platform and deployment target, so scenario questions about building a native mobile app versus a browser app versus a desktop app get answered by name recognition rather than by requirement matching.
The SDK lineup is the most visible, easily listed fact in the foundation material, so candidates build a flashcard list instead of a decision framework. Exam items rarely ask 'name the SDKs'; they describe a platform, an offline requirement, or an existing codebase and ask which SDK or API fits.
What to do instead
Build a one-page matrix: rows are platforms (browser, iOS, Android, Windows desktop, Linux, cross-platform), columns are requirements (offline editing, native UI, 3D, existing Java/.NET codebase, web map reuse). For each cell write the SDK you would choose and one sentence of justification. Practice by reading a scenario and stating the platform constraint first, then the SDK, then the reason.
Treating the ArcGIS REST API and the portal/online item and sharing model as one topic, then failing questions that ask where a specific operation lives, such as whether a task is a service-level REST operation, a portal sharing/permission action, or a client SDK convenience method.
Portal, services, and SDKs are taught together because they are used together, so the boundaries blur. Candidates learn the happy path of publishing and consuming an item and never separate the layers, which is exactly what the exam probes.
What to do instead
Draw the stack explicitly: portal (items, sharing, groups, tokens) on top, GIS services (feature, map, image, geometry, geocoding, geoprocessing) in the middle, REST endpoints as the contract, SDKs as clients. For each operation you study, write which layer owns it and what the REST endpoint pattern looks like. Then answer practice scenarios by naming the layer before the answer.
Confusing authentication patterns: mixing up API keys, OAuth 2.0 user authentication, app authentication (client credentials), and ArcGIS identity/token-based access, and applying the wrong one to a scenario such as a public map versus a private feature layer edit versus a server-to-server job.
All four are described as 'ways to authenticate', and candidates memorize the names without the constraint that selects each one: whether there is a signed-in user, whether the app can keep a secret, and whether the resource is public or private.
What to do instead
Make a decision tree keyed on three questions: Is there an end user? Can the app hold a client secret safely (server-side versus browser or mobile)? Is the resource public? Walk every auth scenario through the tree and record the resulting pattern plus one reason. Note explicitly that secrets must never ship in client-side code.
Assuming a layer or service can do something because the client SDK exposes a method for it, without checking the underlying service capability, so questions about editing, querying with statistics, attachments, or offline use on a specific layer type are answered from the API surface rather than the service contract.
Documentation browsing is method-first: candidates find a function and assume it works everywhere. In practice the service type (feature layer versus map image layer versus stream layer) and its published capabilities determine what is possible, and the SDK method fails or is unsupported otherwise.
What to do instead
For each layer type you study, keep a capability row: query, edit, attachments, related records, statistics, sync/offline, time awareness. When you meet an SDK method, ask which service capability it depends on and verify it in the service metadata. Practice by reading a scenario, naming the layer type, then listing its capabilities before choosing an approach.
Skipping the portal item and sharing model details, such as item types, ownership, groups, sharing levels, and how a web map references its layers, so questions about why a shared map breaks for another user or what an item ID represents are missed.
The item model looks like administrative plumbing rather than developer content. Candidates focus on code and treat portal concepts as background, but many foundation questions hinge on how items reference services and how permissions propagate.
What to do instead
Trace one complete example end to end: a feature layer service published from data, registered as a portal item, added to a web map item, shared to a group, opened in an app. At each hop write what is stored (item ID, URL, ownership, sharing) and what breaks if that hop is missing. This single trace covers most item-model questions.
Confusing coordinate systems, spatial references, and projections, and treating them as interchangeable, so questions about why data appears in the wrong place, when reprojection happens, or what a spatial reference object contains are answered with the wrong term or the wrong stage of the pipeline.
The vocabulary overlaps in casual use, and candidates learn 'set the spatial reference' as a single step. The exam distinguishes geographic versus projected coordinate systems, the role of the spatial reference on a service versus a client view, and where transformation occurs.
What to do instead
Write precise definitions for coordinate system, spatial reference, projection, and datum transformation. Then map the pipeline: data storage spatial reference, service spatial reference, client map spatial reference, and where on-the-fly projection happens. Practice diagnosing a mislocated feature by naming which stage introduced the mismatch.
Memorizing geometry and spatial analysis operation names (buffer, intersect, union, clip, spatial relationship predicates) without knowing their input geometry types, output types, and which are client-side geometry engine operations versus server-side geoprocessing services.
Operation names are short and list-like, so they get memorized as vocabulary. Exam items instead ask what a given operation returns, whether it can run offline in the client, or which predicate matches a described spatial relationship.
What to do instead
For each operation record input geometry type, output geometry type, and execution location (client geometry engine versus server geoprocessing). For spatial predicates, write a one-line plain-language test for each (for example, what must be true for one geometry to contain another). Then solve small scenarios by hand before checking the API.
Treating offline capability as a single yes/no property, so questions about which layer types support offline use, what a sync operation does with edits made while disconnected, and what must be prepared before going offline are answered with a blanket 'it works offline'.
Offline is taught as a feature bullet. The real constraints are layer type, whether the service supports sync, what gets taken offline (basemap, layers, attachments), and how conflicts are resolved on reconnect, and candidates never separate these.
What to do instead
Build an offline checklist: supported layer types, sync-enabled service requirement, pre-take-offline preparation steps, local edit storage, and the sync/reconnect step including conflict handling. Walk a field-collection scenario through the checklist start to finish, naming what happens at each step.
Answering questions about the ArcGIS Maps SDK for JavaScript object model by pattern-matching class names, without knowing the map-view-layer structure, the difference between a Map and a View, or how layers are added and ordered, so questions about the lifecycle or about 2D versus 3D views are missed.
The JavaScript SDK has many classes and candidates learn them as a name list. The exam tests structural understanding: what owns what, what a view does, and how the same map can be rendered in different views.
What to do instead
Draw the object graph: Map contains layers and a basemap; a View (2D MapView or 3D SceneView) renders a Map and owns the camera and extent; layers reference services or client-side data. Then write the minimal code sequence to create a map, add a layer, and display it in both view types, describing what changes and what stays the same.
Ignoring error handling, token expiry, and rate or request limits, so questions about what a well-built app should do when a request fails, a token expires mid-session, or a service returns an error are answered as if the happy path always holds.
Study material emphasizes building the working feature, and error paths are rarely the focus of tutorials. Candidates therefore treat failure handling as an afterthought, but foundation items often test whether the candidate knows the failure modes of authenticated, networked GIS calls.
What to do instead
For each call pattern you study, write the failure modes: invalid or expired token, insufficient privileges, service unavailable, quota exceeded, malformed geometry. Then write the correct handling behaviour for each (refresh token, prompt re-authentication, retry with backoff, surface a clear error). Keep this as a checklist you apply to every scenario you practice.