Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Ok, I sort of missed the not having them too close bit from your explanation. The conversion between the coordinates is very slow. The way you can alleviate it is to precompute the coordinates into map points with <code>MKMapPointForCoordinate</code> and store them persistently - they only depend on the coordinates. Then you can quickly calculate the distance between the map points of two annotations, scale it depending on your current zoom level of the map and this will quite closely relate to the actual distance on the screen. It should be accurate enough and will be much faster.</p> <p>I would recommend calculating the squared distance and comparing it to squared <code>dist</code>. You would be saving a lot on the <code>sqrt()</code>.</p> <p>If you still get boggled down on <code>getDist()</code> (or <code>getSqDist()</code>) you could either go for a kd tree or use the Accelerate Framework to do the calculations. I've done the latter when I needed to calculate distances between many points and the speedup was very good. But the details of this is an another cup of tea. Let me know if you need any help with that.</p> <p>The fact that your coordinates are indexed would only help if you actually searched for annotations by the coordinates, so it won't help if you just look through all of them.</p> <p>A way of dealing with long loading times from CoreData would be to try making your annotations as lightweight as possible, so only storing the coordinates and map points. Then you could have a way of getting the rest of the annotation data as needed. This could be done with the proxy pattern.</p> <p>One more thing. Fast enumeration might be faster and is better practice as well, so</p> <pre><code>for(LocationEntity* thisLocation in locations) </code></pre> <p>instead of</p> <pre><code>for (int i =0 ; i &lt; [locations count]; i++) </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POOptimization for MKAnnotations and Core Data
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMaciej Trybiło
    1. USMaciej Trybiło
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOptimization for MKAnnotations and Core Data
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COYes, but I don't want them to be too close to each other so some kind of filtering is necessary. I know it's redundant to check here, but it's just a comparison.
      singulars
      1. PO
      1. USTemplar
    2. COOk, check my updated answer.
      singulars
      1. PO
      1. USMaciej Trybiło
    3. COThanks for the long answer :) I thought about caching somehow those points for the locations, but hoped that it will be a simpler method. Too bad there is not a simple approximation for MKMapPoint->CGPoint :)
      singulars
      1. PO
      1. USTemplar
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload