Là nhà phát triển C #, bạn sẽ học Java để phát triển cho Android hoặc sử dụng MonoDroid thay thế? [đóng cửa]


46

Tôi cho rằng bản thân mình khá thành thạo C #. Đó là ngôn ngữ mà tôi lựa chọn vào lúc này và về cơ bản tất cả là kinh nghiệm nghề nghiệp của tôi.

Tuy nhiên, tôi vẫn bối rối trước sự tồn tại của dự án MonoDroid . Sự hiểu biết của tôi luôn luôn là C # và Java rất gần nhau. Giống như, nếu bạn biết một, bạn có thể học cái khác thực sự nhanh chóng. Vì vậy, khi tôi cân nhắc phát triển ứng dụng Android đầu tiên của mình, tôi chỉ cho rằng tôi sẽ làm quen với Java đủ để bắt đầu và sau đó chỉ cần học khi tôi đi.

Điều này sẽ không có ý nghĩa hơn so với việc sử dụng MonoDroid, có khả năng ít giàu tính năng hơn SDK Android Java và yêu cầu học API riêng của nó (mặc dù là API .NET)? Tôi chỉ cảm thấy sẽ tốt hơn nếu học một ngôn ngữ mới (và một ngôn ngữ cực kỳ phổ biến ở đó) và có được một số kinh nghiệm về nó. với, mà không đạt được bất kỳ kỹ năng có giá trị hơn.

Có lẽ tôi đang đánh giá sai về người dùng MonoDroid tiềm năng trung bình. Có lẽ nhiều hơn cho những người có kinh nghiệm về Java và .NET và chỉ thích .NET. Hoặc có thể (trên thực tế có khả năng) có những yếu tố khác mà tôi chưa xem xét. Tôi chỉ tự hỏi, tại sao bạn lại sử dụng MonoDroid thay vì chỉ phát triển cho Android bằng Java?


11
Google cụm từ "là COBOL mới" và xem google sử dụng ngôn ngữ nào ...
John Reynold

1
@JohnReynold mỉa mai rằng sự tăng trưởng nhanh nhất hiện nay là trên thiết bị di động và Android, sử dụng "COBOL mới". Dù bạn cắt lát theo cách nào, ngay cả khi bạn chọn MonoDroid, nếu bạn đang phát triển cho Android, bạn vẫn đang dựa vào "COBOL mới".
Jason S

1
"COBOL mới" dùng để chỉ ngôn ngữ, không phải VM (có thể là JVM hoặc Dalvik). Vì vậy, MonoDroid không dựa vào "COBOL mới" và Scala và Clojure cũng như bất kỳ ngôn ngữ JVM nào khác.
John Reynold

Cũng có một lượng lớn COBOL cũ vẫn còn tồn tại.
Alan B

@JohnReynold Điều trớ trêu là hầu hết các mã đang chạy ngày nay là COBOL; và trớ trêu nhất là C # là một bản sao của Java (và là một người nghèo vì nó cũng nhân bản hầu hết những điều sai trái).
m3th0dman

Câu trả lời:


55

Bất kỳ lập trình viên C # có thẩm quyền nào cũng có thể nhanh chóng chọn đủ Java để viết chương trình Android, nhưng đó không phải là vấn đề . Đó là vấn đề tái sử dụng mã.

Hãy suy nghĩ về sáu tháng kể từ bây giờ, khi chương trình Android của bạn phổ biến và người dùng của bạn đang yêu cầu phiên bản cho iPhone và Windows Phone 7. Nếu bạn đã sử dụng MonoDroid, bạn có thể sử dụng lại hầu hết logic ứng dụng của mình với MonoTouch (Mono cho iOS) và SDK điện thoại Windows. Bây giờ họ muốn có một phiên bản dựa trên web, vì vậy bạn bao gồm các thư viện cùng lớp trong một dự án ASP.Net. Phiên bản máy tính để bàn? Không có vấn đề gì, thư viện cùng lớp đó hoạt động với .Net trong Windows hoặc Mono trên Linux và OS X.

Khác với C hoặc C ++, tôi không thể nghĩ ra bất kỳ ngôn ngữ nào khác cho phép bạn sử dụng lại cùng một mã trên tất cả các mục tiêu đó.

Chỉnh sửa để giải quyết một số lo ngại trong các nhận xét: .Net và Mono sẽ không cho phép bạn viết một chương trình hoàn chỉnh và sử dụng cùng một chương trình đó ở mọi nơi. Họ sẽ cho phép bạn chia sẻ một số mã và giống như tất cả các chương trình đa nền tảng, số lượng mã được chia sẻ tùy thuộc vào loại chương trình bạn đang viết và mức độ tách biệt UI và mã phần cứng khỏi logic ứng dụng.

Tuy nhiên, nếu bạn viết ứng dụng Android của mình bằng Java, bao nhiêu trong số đó có thể tái sử dụng trên iOS hoặc Windows Phone? Đó là điểm tôi đang cố gắng thực hiện. Tôi đã có các thư viện C # hiện đang hoạt động trên Mono cho Android trong thời gian ngắn hơn nhiều so với việc thực hiện lại chúng, mặc dù tôi đã biết Java . Tôi có một số mã được chia sẻ - chưa sửa đổi - giữa một trang web, chương trình máy tính để bàn và ứng dụng di động trên hai nền tảng di động khác nhau, nhờ Mono.

Tôi không có ý ám chỉ, thậm chí gián tiếp, rằng Mono là công cụ hoàn hảo cho mọi tình huống phát triển di động. Đó là một sự đánh đổi, nhưng tôi tin chắc rằng có những tình huống khi Mono là lựa chọn tốt hơn nhiều.

Xin vui lòng xem (và upvote!) Câu trả lời của Jason S cho một góc nhìn khác.


12
Và tôi đã nghĩ rằng Java là người có khẩu hiệu "viết một lần chạy khắp nơi"!
Luciano

3
@Luciano - các đối số tương tự có thể được áp dụng nếu OP nói rằng anh ta biết Java vì đang tự hỏi có nên học C # không. Bit quan trọng là tái sử dụng mã, không phải ngôn ngữ.
ChrisF

14
Mono đã được chọn trong nhà vì lý do tương tự. Chúng tôi cần xây dựng một máy khách trong nhiều nền tảng và tất cả các lập trình viên c # mới. Về lý thuyết, đó là một ý tưởng tuyệt vời. Tuy nhiên, trên thực tế, nó đã biến thành một cơn ác mộng. Chúng tôi đã tìm thấy nhiều nơi mã hoạt động trong nền tảng .NET gốc sẽ không hoạt động trong nền tảng MacOS, vì vậy chúng tôi phải tạo một ngoại lệ; sau đó cùng một mã không hoạt động trong LInux. Nhìn chung, mono dường như quá không ổn định. Cuối cùng, chúng tôi đã phải từ bỏ ý tưởng và quay lại viết mã gốc cho HĐH được nhắm mục tiêu.
Chu

4
Tuy nhiên, mã duy nhất có thể sử dụng lại là logic nghiệp vụ, không phải mã UI hoặc mã tương tác với phần cứng điện thoại. Xem Tôi có ứng dụng MonoTouch hoặc WindowsPhone 7, tôi có thể xây dựng lại nó bằng Mono cho Android và nhắm mục tiêu Android không? trên Câu hỏi thường gặp về MonoDroid.
Jason S

2
@JasonS, tôi đã cập nhật câu trả lời của mình để giải quyết bình luận của bạn. Đối với hồ sơ, sự tham gia duy nhất của tôi với Xamarin và Mono là một người dùng hài lòng.
Kevin

18

Đây là một loại câu trả lời bổ sung, vì một điều dường như đã bị bỏ qua trong các câu trả lời cho đến nay, liên quan đến những gì thực sự là đa nền tảng. Theo chính Xamarin, về cơ bản là logic kinh doanh của bạn, không phải giao diện người dùng hoặc bất kỳ điều khiển phần cứng nào như GPS, âm thanh, sổ địa chỉ, v.v. Những người sẽ phải được viết riêng cho từng nền tảng. Xem mục Câu hỏi thường gặp của họ Tôi có ứng dụng MonoTouch hoặc WindowsPhone 7, tôi có thể xây dựng lại nó bằng Mono cho Android và nhắm mục tiêu Android không? .

Sử dụng Mono, bạn có thể viết mã điều khiển giao diện người dùng và điện thoại của mình bằng C # nhưng nó sẽ không khả dụng cho bất kỳ nền tảng nào. Bạn sẽ phải viết UI và điều khiển điện thoại cho từng nền tảng, mặc dù bạn có thể viết nó bằng C #. Dù bằng cách nào, bạn vẫn sẽ phải tìm hiểu các chi tiết cụ thể về kiểm soát giao diện người dùng trên Android và cách Android xử lý tài nguyên điện thoại.

Sử dụng Mono, bạn sẽ phải tìm hiểu API Mono, gọi vào API Android. Bạn cũng sẽ phải chờ Mono triển khai các tính năng mới của Android và hy vọng họ triển khai tất cả các tính năng của Android. Ngay cả khi C # mạnh hơn Java, bạn sẽ không thể làm được nhiều hơn nếu bạn sử dụng SDK Android trực tiếp (bằng Java).

Nếu bạn đang đi thẳng từ C # sang Android, vì C # rất giống với Java về mặt cú pháp, thì hầu hết việc học của nhà phát triển C # cho Android sẽ học API Android.

Một số cân nhắc ...

C # cho Android

Cần học

  • API Android
  • API Java: Xử lý chuỗi, lịch và sự kiện, v.v.

Không cần học

  • Cú pháp Java: C # là cú pháp rất giống nhau.

Những ý kiến ​​khác

  • Bạn sẽ không thể sử dụng lại mã trên các nền tảng.
  • Bạn sẽ không có bất kỳ sự phụ thuộc nào giữa bạn và SDK Android. Bạn sẽ nhận được các tính năng Android mới khi chúng được phát hành.
  • Bạn có thể sẽ có sự hỗ trợ và ví dụ lớn hơn cho mã Android so với Mono.

C # đến Mono

Cần học

  • Android: Bạn vẫn cần tìm hiểu các tính năng kiểm soát phần cứng và giao diện người dùng của Android.
  • API đơn sắc: Bạn phải học cách gọi API của Mono để làm mọi thứ với giao diện người dùng và phần cứng của Android.

Không cần học

  • API và cú pháp Java: Bạn có thể phát triển bằng C #

Những ý kiến ​​khác

  • Sử dụng lại mã: Bạn có thể sử dụng lại mã C # không có bất kỳ mã kiểm soát giao diện người dùng hoặc phần cứng nào và đó là "logic kinh doanh" thuần túy. Mặc dù lý tưởng, có một sự tách biệt sạch sẽ như vậy không phải lúc nào cũng dễ dàng. Bạn sẽ phải đánh giá bao nhiêu mã của bạn sẽ không có bất kỳ kiểm soát UI hoặc phần cứng nào.
  • Phụ thuộc: Bạn phụ thuộc vào Mono triển khai API Android. Có thể có một số độ trễ từ bản phát hành API Android hoặc một số tính năng Android có thể không bao giờ được thực hiện.
  • Bạn có thể có ít tài liệu và ví dụ để lựa chọn.

Bạn đã quên đề cập đến P / Gọi. Một ví dụ.
Amir Karimi

-1: Ý bạn là Learn the Mono APIgì? Bạn thực sự cần biết bao nhiêu để phát triển ứng dụng Android? Và bạn đã thực sự thử MonoDroid hay bạn đang đoán?
Jim G.

@JimG. Bởi Learn the Mono API, ý tôi là bạn vẫn cần học API Android mà Mono sao chép, ngoài những phần không có. Bạn cần biết bao nhiêu? Phụ thuộc vào ứng dụng, tùy thuộc vào từng người - đó thực sự không phải là ý chính của OP. Tôi đã sử dụng MonoDroid? Không. Tôi có kinh nghiệm về C #, Java và Objective C, nên không cần. Tôi đã xem xét Mono cho tính di động. Tại thời điểm tôi trả lời không ai đã đề cập đến các giới hạn về tính di động. Tôi không ngại mọi người không đồng ý với tôi, nhưng chính điều đó không làm cho câu trả lời của tôi trở nên nghèo nàn.
Jason S

13

Tôi nghĩ rằng rất nhiều trong số đó phải làm với các tài nguyên có sẵn.

Các cú pháp trong C # và Java có thể tương tự, nhưng họ cung cấp những điều rất khác nhau. Ví dụ, làm việc với các ngày sử dụng các thư viện Java tiêu chuẩn là một cơn ác mộng, trong khi ở C # thì khá dễ chịu.


2
Thú vị vì vậy sự hấp dẫn là về việc truy cập vào các thư viện .NET. Bạn có biết .NET có cung cấp nhiều chức năng tiện lợi, phù hợp với Android không, điều đó khó đạt được hơn với các API Java Android?
Dan Tao

19
+1 - Đến từ C #, tôi thấy java trở nên ... bình dị nhất ...
Oded

4
Tôi thấy rằng sự tương đồng giữa C # và Java không phải là một lợi thế khi chuyển đổi giữa chúng. Tôi có thể chuyển đổi giữa C # và Python, Ruby hoặc Lua mà không cần chớp mắt, nhưng lần cuối cùng tôi thử thực hiện một số mã hóa Java, cuối cùng tôi đã nghiến răng và quay bánh xe.
Adam Crossland

1
@ Dan Tao: sự hấp dẫn không phải là nhiều hơn về quyền truy cập vào tiêu chuẩn Net. Đó là về cả hai và sử dụng lại. Lợi ích của việc tái sử dụng nên rõ ràng. Đối với quyền truy cập vào .Net, tôi nhìn vào nó theo cách này. Tôi đã sử dụng, giả sử, XDocument 1000 và 1 lần. Nếu tôi cần viết một ứng dụng di động tích hợp dữ liệu XML từ một dịch vụ, tôi sẽ viết nó với tốc độ suy nghĩ. Nếu tôi đang học Java, tôi có thể dễ dàng mất gấp 4 đến 8 lần (hoặc 10 hoặc 12, ai biết) nảy qua lại giữa mã hóa và đọc tài liệu. Nếu việc sử dụng là cho kinh doanh, việc thực hiện một dự án trong khi học một ngôn ngữ là vô trách nhiệm.
quentin-starin

9

Có vẻ như một cơ hội tuyệt vời để học một ngôn ngữ mới , mà tôi không nghĩ bạn nên bỏ qua.

Đi từ C # sang Java rất dễ dàng vì chúng dựa trên các khái niệm tương tự. Java giống như một tập hợp con của C #, vì vậy bạn sẽ phải học một số nội dung (như thuộc tính và tập hợp) và làm quen với một số quy ước mới, nhưng chủ yếu là nó không có trí tuệ.


10
Và tìm ra sự khác biệt giữa cách thức hoạt động của thuốc generic trong mỗi loại, và tự hỏi tại sao các thuộc tính không tồn tại, và các sự kiện và ...
Oded

5
Khác biệt nhỏ. Nó không giống như anh ta phải học Haskell.
Martin Wickman

1
+1 Không có hại khi biết một vài ngôn ngữ khác nhau và có một dự án trong thế giới thực để làm việc là một cách tuyệt vời để hiểu được nếu đó là một loại ngôn ngữ tương tự như những ngôn ngữ bạn đã biết.
glenatron

Tốt hơn hãy chắc chắn rằng người trả tiền là ok trả tiền cho một kinh nghiệm học tập.
quentin-starin

1
@qes - Học một cái gì đó dư thừa không đủ lý do để biện minh cho chi phí trong hầu hết các trường hợp, nhưng việc phát triển một ứng dụng phức tạp trong môi trường tự nhiên của nó sẽ diễn ra suôn sẻ hơn và điều đó có thể khiến việc học có nhiều hơn giảm chi phí dài hạn.
Morgan Herlocker

3

Bài học lịch sử nhanh - MonoDroid lớn lên từ MonoTouch. Làm rất nhiều ý nghĩa tại thời điểm đó. Thật không may, Novell đã bị bán và toàn bộ đội Mono đã bị sa thải. Tin tốt là Miguel de Icaza đã bảo đảm kinh phí và đã bắt đầu một bộ trang phục mới để xây dựng lại MonoTouch / MonoDroid. Vì vậy, bạn là loại trong limbo cho đến khi họ thực sự ra mắt.

Cập nhật tháng 7 năm 2011: Trang phục của Miguel đã lấy lại quyền đối với toàn bộ ngăn xếp Mono *. Nhận nó trong khi nó diều hâu.


Tốt để nghe (Cập nhật tháng 7 năm 2011). Tôi đã thử Mono trước đây và thấy nó hơi thất vọng. Tôi sẽ thử lại lần nữa!
Brian Knoblauch
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.