2011-10-07 27 views
5

Tôi có một ứng dụng, ứng dụng hiện có trong cửa hàng ứng dụng.Hai ứng dụng, một mã số. Làm thế nào tôi có thể đạt được điều này?

Tôi có ý tưởng về một ứng dụng khác, ứng dụng này sẽ chia sẻ rất nhiều cấu trúc giống như ứng dụng đã xuất bản của tôi. Cả hai đều là các ứng dụng thao tác hình ảnh, do đó, mã cơ sở để nhập, chia sẻ, lưu, xoay, v.v ... sẽ được chia sẻ giữa hai ứng dụng. Tuy nhiên, kiểu thao tác ảnh sẽ khác.

Suy nghĩ của tôi là khi tôi cập nhật ứng dụng # 1, tôi muốn những thay đổi đó trong ứng dụng số 2 và ngược lại.

Cách tốt nhất để đạt được hai ứng dụng từ một codebase là gì?

Chiến lược Tôi đã dự tính,

  1. Một tập tin dự án, hai mục tiêu. Bằng cách đó, codebase cho cả hai ứng dụng sẽ luôn được cập nhật, mặc dù tệp/thư mục dự án sẽ hơi lộn xộn, để chắc chắn.
  2. Chi nhánh ứng dụng trong git, thường xuyên hợp nhất các thay đổi giữa hai nhánh cho các lớp được cả hai sử dụng.

Tôi cũng đang mở cho các ý tưởng khác.

Tôi đã tìm thấy mọi người thảo luận về điều này, nhưng chủ yếu liên quan đến những thay đổi nhỏ ... tức là một ứng dụng có một vài tệp thương hiệu/dữ liệu khác nhau. Hai ứng dụng của tôi sẽ khác biệt một cách hợp lý, vì vậy tôi không nghĩ rằng các kỹ thuật đó nhất thiết phải áp dụng.

+0

Nhân tiện, tôi đã xóa thẻ 'nhiều mục tiêu' vì nó rất phù hợp và bạn có thể sử dụng cái gì đó chung chung hơn để có được điểm trên, như' target-target'. – darvids0n

Trả lời

2

Tôi đề nghị chia ứng dụng hiện tại của bạn thành HAI phần. Tách ra tất cả các phần phổ biến như một thư viện DLL/lớp chung, và sử dụng dll trong cả dự án hiện tại và mới của bạn.

Khi tiến trình phát triển dự án đầu tiên diễn ra, hãy sử dụng phiên bản dll mới nhất trong dự án mới hơn của bạn, sử dụng các tập lệnh triển khai thích hợp. Bằng cách này, dự án mới của bạn thậm chí có thể nằm trong một codebase riêng biệt

+1

oops im sử dụng thuật ngữ .net. Chuyển đổi chúng thành thuật ngữ c mục tiêu khi thích hợp – Zasz

+1

Thư viện tĩnh sẽ là tương đương phù hợp. Nội dung của Apple hỗ trợ các thư viện động (như các tệp DLL), nhưng bạn không được phép sử dụng thư viện động hoặc khung công tác trong ứng dụng Cửa hàng ứng dụng iOS. –

3

Tạo một thư viện tĩnh với thao tác ảnh thông thường hoặc các chức năng được chia sẻ khác của bạn và làm lại dự án hiện tại để thêm thư viện làm phụ thuộc và sử dụng thư mục tiêu đề của thư viện trong Đường dẫn tìm kiếm tiêu đề người dùng. Sau đó, bạn về cơ bản có thể sao chép dự án cũ của bạn và bắt đầu sửa đổi ngay lập tức với quyền truy cập vào tất cả các chức năng thư viện được chia sẻ.

Hai mục tiêu của cùng một dự án có vẻ áp dụng cho trường hợp của bạn. Nếu bạn có một lượng lớn chồng chéo thì bạn chỉ cần viết UI/luồng công việc thứ hai cho điều đó, đúng không? Nếu có, sử dụng hai mục tiêu làm cho rất nhiều ý nghĩa.

+1

Các phần tôi muốn sao chép giữa hai dự án chủ yếu là * cấu trúc ứng dụng *. Tôi nghi ngờ rằng bạn thậm chí có thể có một App Delegate được gọi là từ một thư viện được chia sẻ ... tương tự, các tập tin nib? Điều này giống như kỹ thuật sai đối với ứng dụng ca cao. Bạn đã sử dụng kỹ thuật này trước đây chưa, nó đã đi như thế nào? –

+0

Tôi sử dụng thư viện tĩnh cho trình phát phim tùy chỉnh. Để sử dụng thư viện, tôi cần phải thêm tiêu đề vào đường dẫn tìm kiếm và thêm thư viện làm phụ thuộc, nhưng cũng sao chép trên một '.xib' chứa chế độ xem của trình phát. Tôi cho rằng hoạt động một lần bình thường để cho phép dự án của tôi sử dụng lớp trình phát phim tùy chỉnh. Tôi đã không cố gắng gọi một đại biểu ứng dụng từ một thư viện, nhưng nó gần như chắc chắn không phải những gì bạn thực sự muốn. Tôi sẽ bắt đầu một thư viện với chế độ xem gốc của cấu trúc ứng dụng * của bạn * trái ngược với lớp ủy nhiệm ứng dụng. Bạn luôn có thể '# import' trong lớp ủy nhiệm. – darvids0n

2

Tôi khuyên bạn nên xem xét sử dụng các mô đun phụ git trong cả hai ứng dụng của bạn. Điều này đã làm việc hoàn hảo cho chúng tôi khi chia sẻ mã trong nhiều ứng dụng. Cơ bản chúng tôi sử dụng một cấu trúc mà chúng tôi trong mỗi dự án Xcode có một thư mục "Components/" nơi chúng tôi giữ mô-đun con.

App A có thể có các môđun con như thế này:

Components/SomeAmazingPhotoManipulationStuff 
Components/MaybeSomeUsefullFoundationThingsYouUseOften 

App B chỉ có thể sử dụng:

Components/MaybeSomeUsefullFoundationThingsYouUseOften 

Ý tưởng ở đây là bạn có thể cập nhật các dự án submodule của bạn một cách riêng biệt và chỉ cần đi vào từng Ứng dụng được sử dụng và cập nhật mô-đun con thành phiên bản mới nhất của thành phần, chia sẻ thành công nội dung giữa các ứng dụng mà không mất quyền kiểm soát phiên bản.Nó cũng sẽ mở rộng quy mô tốt cho nhiều dự án.

Và bạn có thể phân nhánh các mô-đun con của mình và ứng dụng A sử dụng một nhánh và ứng dụng B khác, nếu bạn thực hiện một số nội dung cụ thể hoặc công cụ rất thử nghiệm trong một ứng dụng hoặc bất kỳ tình huống nào bạn có thể nghĩ đến.

Kể từ khi chúng tôi bắt đầu sử dụng các mô đun con git như thế này, chúng tôi đã không xem xét lại hoặc thậm chí xem xét bất kỳ giải pháp nào khác.

+1

GIT submodules chắc chắn là một công cụ tôi muốn giới thiệu để sử dụng. Trên thực tế, tôi sẽ kết hợp tất cả các câu trả lời nhất định. Sử dụng các mô-đun con cho các thư viện tĩnh tùy chỉnh của bạn. Bằng cách đó bạn nhận được tất cả các lợi ích; kiểm soát phiên bản thích hợp (git submodules), cấu trúc ứng dụng thích hợp (thư viện tĩnh), mã có thể chia sẻ tốt giữa các đồng nghiệp (cả hai), được giao trách nhiệm giữa các đồng nghiệp (cả hai), ... – Till

Các vấn đề liên quan